Blazor WebAssembly文件上传：StreamContent对比带byte[]的DTO

先纠正一个常见误区：StreamContent方案不需要发起两次请求，你可以把附加数据和文件一起封装到MultipartFormDataContent里，一次请求完成上传，示例代码如下：

var content = new MultipartFormDataContent();
// 添加文件流
content.Add(new StreamContent(file.OpenReadStream(maxFileSize)), "file", file.Name);
// 添加附加元数据
content.Add(new StringContent("文档分类"), "category");
content.Add(new StringContent("用户ID123"), "uploaderId");

await Http.PostAsync("/api/files/upload", content);

接下来聊聊两种方案的核心差异，以及几MB文件场景下StreamContent的优势：

1. 内存占用的本质区别 #

• DTO+byte[]方案：必须将整个文件一次性加载到客户端内存中——byte[]类型会直接把文件的所有字节存入内存，直到上传完成并触发垃圾回收。比如5MB的文件，客户端内存会瞬间增加5MB，若同时上传多个文件，内存占用会线性叠加。
• StreamContent方案：通过file.OpenReadStream()获取的是浏览器提供的流式读取能力，文件会被分块读取（默认分块大小由浏览器控制，通常是几KB到几十KB），每上传完一块就释放对应内存，内存峰值远低于文件总大小。哪怕是5MB的文件，内存峰值可能只有几十KB，不会一次性占用大量内存。

2. 几MB文件场景下的优势依然存在 #

不要觉得几MB的文件小就无所谓：

• 浏览器的内存是共享资源，若你的Blazor应用本身有复杂组件、状态管理或其他内存占用高的逻辑，叠加文件的内存占用可能导致页面卡顿、响应变慢；
• 若用户需要同时上传多个几MB的文件，DTO方案的内存占用会直接翻倍、三倍，而StreamContent方案的内存峰值几乎不变；
• 扩展性更好：如果后续业务需求允许上传更大的文件（比如几十MB），StreamContent方案无需修改核心逻辑，而DTO方案会直接出现内存溢出或浏览器无响应的问题。

3. 额外优势 #

StreamContent方案还能配合服务器端的流式接收，实现端到端的流式上传，进一步降低服务器端的内存压力，这是DTO+byte[]方案做不到的——服务器端接收byte[]时也需要一次性加载整个文件到内存。

内容的提问来源于stack exchange，提问作者Sam