ASP.NET Core 返回大文件应优先用FileStreamResult，由框架自动处理流式传输、分块和断点续传；禁用内存全载，正确配置FileStream参数与响应头；手动流式需用CopyToAsync并禁用缓冲；PushStreamContent已移除，部署时须调优反向代理设置。
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 或 IAsyncEnumerable 手动拼装响应体，这反而增加 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）
