应使用opendownloadstreamasync配合显式buffersize参数调用copytoasync，避免默认小缓冲导致的高频解析与拷贝；优先用objectid查找跳过files集合查询，并增大chunksizebytes至4mb以减少bson解析开销。
直接用 GridFSDownloadStream.Read() 或 CopyToAsync() 一次性拉取大文件，吞吐不会高——它只是把压力从内存转移到了驱动层解析和缓冲区拷贝上。真正提升吞吐的关键，在于让流消费节奏匹配底层 chunk 拉取节奏，并绕过不必要的内存中转。
为什么 GridFSDownloadStream 默认吞吐低
根本原因不是网络或磁盘慢，而是 .NET 驱动在读取每个 BSON chunks 文档时，都要反序列化 _id、n、data 字段，再把 data 拷贝进托管 Buffer。默认 chunkSizeBytes 是 255KB，一个 500MB 视频要处理近 2000 个 chunk，光 BSON 解析就吃掉大量 CPU。
- 用
bucket.OpenDownloadStreamByName("x.mp4")查找 + 读取，会多一次files集合查询 round-trip - 没显式设
bufferSize的FileStream写入目标，会触发频繁小写，拖慢整体 pipeline - 忽略
GridFSDownloadStream是单次消费流：重复调用ReadAsync或试图Seek会静默失败或抛ObjectDisposedException
用 OpenDownloadStreamAsync + 自定义 bufferSize 控制吞吐
吞吐瓶颈常卡在“每次从流里拿多少字节”和“写到哪去”。.NET 的 GridFSDownloadStream 本身不暴露内部 chunk 边界，但你可以用 CopyToAsync 的 bufferSize 参数强制控制每次搬运量——这直接影响底层驱动的预读行为和 GC 压力。
- 设
bufferSize: 1024 * 1024 * 2（2MB）：比默认 8KB 高效得多，减少CopyToAsync内部循环次数，也降低 Buffer 分配频次 - 避免传
0或不传：.NET 会 fallback 到 8192，对视频/备份类大文件太小 - 别用
stream.ReadAsync(buffer, ...)手动循环：容易漏掉最后不足 buffer 大小的部分，且无法利用CopyToAsync内部优化的 Span路径
示例（写入本地文件）：
using var stream = await bucket.OpenDownloadStreamAsync(fileId);
using var file = new FileStream("out.bin", FileMode.Create, FileAccess.Write, FileShare.None, 65536, FileOptions.SequentialScan);
await stream.CopyToAsync(file, 2 * 1024 * 1024); // 关键：显式传 bufferSize
绕过 FileStream 缓冲，直连网络响应流
当目标是 HTTP 响应（如 ASP.NET Core 中返回视频），不要先写磁盘再 PhysicalFile——那会多一倍 I/O，还失去流控能力。直接把 GridFSDownloadStream 管道到 HttpResponse.Body，但必须手动设 Content-Length 和 Accept-Ranges，否则浏览器无法拖动。
-
HttpResponse.Body是可写的，但不支持Seek，所以不能用CopyToAsync默认的length校验逻辑；必须提前知道file.Length - 务必在
CopyToAsync前调用Response.ContentLength = file.Length，否则 Kestrel 会退化为 chunked encoding，禁用拖动 - 加
Response.Headers.Append("Accept-Ranges", "bytes")，不然移动端 Safari 可能拒绝播放 - 监听
Response.OnStarting注册清理逻辑，防止客户端断连后流还在后台拉数据
真正提吞吐的底层动作：改 chunkSizeBytes 和关冗余查询
应用层调优有极限。如果实测吞吐卡在 30–50 MB/s 且 CPU 持续 >70%，说明瓶颈已在驱动解析层。这时必须改 GridFS 存储时的 chunkSizeBytes，并避免元数据查两次。
- 新建
GridFSBucket时传new GridFSBucketOptions { ChunkSizeBytes = 4 * 1024 * 1024 }（4MB）：chunk 数量降为原来的 1/16，BSON 解析开销直线下降 - 改用
OpenDownloadStreamAsync(ObjectId)而非OpenDownloadStreamByName：跳过files集合查找，少一次 round-trip 和 BSON 解析 - 确认 MongoDB 服务端已建索引：
db.fs.files.createIndex({ _id: 1 })（ObjectId 查找快）或{ filename: 1, uploadDate: -1 }（name 查找需按时间倒序取最新）
这些改动不涉及业务代码，但对 100MB+ 文件的首字节延迟和端到端吞吐影响极大——尤其当文件存的是 DICOM、RAW 视频这类不可压缩二进制时，驱动层少一次解析，就少一次内存拷贝和 GC 压力。
