ASP.NET Core 中用 FileStreamResult
直接返回大文件
这是最常用也最稳妥的方式，框架自动处理缓冲、分块传输（
Transfer-Encoding: chunked）和断点续传支持（如果客户端带
Range头）。关键不是“手动流式”，而是让框架接管流的生命周期。
常见错误是先读取整个文件到内存再写入响应——这会触发
OutOfMemoryException或 GC 压力飙升。正确做法是直接把
FileStream交给
FileStreamResult：
FileStream必须以
FileAccess.Read和
FileShare.Read打开，避免被其他进程锁住 不要用
using包裹该流——
FileStreamResult会在响应结束时自动释放它 显式设置
ContentType（如
"application/octet-stream"）和
FileDownloadName（触发浏览器下载）
return new FileStreamResult(
new FileStream(@"D:\bigfile.zip", FileMode.Open, FileAccess.Read, FileShare.Read, 4096, useAsync: true),
"application/zip")
{
FileDownloadName = "bigfile.zip"
};需要自定义响应头或控制流节奏时用 HttpResponse.Body
+ Stream.CopyToAsync
比如要动态计算校验和、加水印、或在响应中插入元数据头，就不能依赖
FileStreamResult。此时需手动写入
HttpResponse.Body，但必须注意：不能调用
Response.Body.WriteAsync一次性写入整个文件，而要用流复制方式控制内存占用。 务必设置
Response.ContentType和
Content-Length（如果长度已知），否则浏览器无法显示进度条 禁用响应缓冲：
Response.Buffering.DisableBuffering()（.NET 6+）或
Response.Headers["X-Accel-Buffering"] = "no"（Nginx 场景） 使用
CopyToAsync并指定
bufferSize（如
81920），避免默认 8192 在高吞吐下成为瓶颈
Response.ContentType = "application/pdf"; Response.ContentLength = fileInfo.Length; await Response.Body.CopyToAsync(fileStream, 81920);
PushStreamContent
是 ASP.NET Core 的陷阱——它根本不存在
很多老文章提到的
PushStreamContent属于旧版 ASP.NET（.NET Framework），在 ASP.NET Core 中已被彻底移除。试图搜索或引用它只会浪费时间。替代方案只有两个： 静态大文件 → 用
UseStaticFiles配合 Nginx/Apache 直接服务（零 C# 开销） 动态生成或需鉴权 → 用
FileStreamResult或手动
CopyToAsync，别找“推送流”抽象
有人尝试用
Channel<byte></byte>或
IAsyncEnumerable<byte></byte>手动拼装响应体，这反而增加 GC 压力且不兼容 HTTP/2 流控，纯属倒退。
部署环境对流式响应的实际影响
本地开发跑通不等于线上可用。反向代理（Nginx、IIS、Cloudflare）常默认缓存或限制单次响应大小，导致流被截断或延迟发送。
Nginx：确认proxy_buffering off;、
proxy_max_temp_file_size 0;，否则它会攒满 1G 再吐给客户端 IIS：检查
web.config中
responseBufferLimit是否为
0（无限制） Kestrel：默认已支持长连接流式，但若前端有超时（如 Cloudflare 的 100 秒免费版），需在代码里加心跳（如定期写入空注释
// keepalive）
最易被忽略的是：某些杀毒软件或企业防火墙会扫描完整响应体才放行，此时无论后端多快，用户都得等全量传输完才开始下载。
