必须使用GridFSBucket.OpenDownloadStream下载文件，它自动处理元数据校验、chunk顺序修复、MD5验证和断点续传；手动查fs.chunks会绕过关键字段并导致数据损坏，且需确保fs.files和fs.chunks有正确索引。
用 GridFSBucket.OpenDownloadStream，别碰 chunks 集合
直接查 fs.chunks 拼数据是错的——OpenDownloadStream 才是唯一受支持的下载入口。它自动处理文件元数据校验、chunk 顺序修复、MD5 验证和断点续传逻辑。手动读 chunks 不仅绕过 filename、uploadDate、metadata 字段，还会在 chunk 缺失或重试失败时返回损坏数据。
必须通过 gridfs.NewBucket(db) 初始化 bucket 实例，不能用已弃用的旧版 gridfs 包（如 mgo 或早期 mongo-go-driver/gridfs 的非 bucket 接口）。
-
OpenDownloadStream接收ObjectID，最稳；若用filename，需注意：同名文件可能有多个版本（靠uploadDate区分），驱动默认取最新（revision = -1） - 错误写法：
collection := db.Collection("fs.chunks")→ 后续自己按n排序拼接 → 容易漏 chunk、跳块、校验失败 - 正确起点：
bucket, _ := gridfs.NewBucket(db)，再调bucket.OpenDownloadStream(id)
下载大文件时必须传 start 和 end 参数
HTTP Range 请求（比如视频 seek、断点续传）必须转成 OpenDownloadStream 的 options，否则驱动会读完整个文件再裁剪，白白放大内存和 I/O 压力。
start 和 end 单位是字节，且语义是左闭右开区间 [start, end)。常见坑：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
start = 1024, end = 1024→ 返回空流，不是报错，客户端可能卡住 -
end = fileLength→ 正确；但写成end = fileLength + 1就越界，驱动内部会静默截断，不报错也不警告 - 不用刻意对齐 chunk 边界（默认 255KB）；驱动会自动跳过无关 chunk，你只管按业务需求传参
示例（解析 HTTP Range 头）：
rangeHeader := r.Header.Get("Range") // "bytes=1000000-1999999"
if start, end, ok := parseRange(rangeHeader, fileSize); ok {
stream, err := bucket.OpenDownloadStream(id, options.GridFSBucketOptions{
Start: &start,
End: &end,
})
}
并发下载多个分块时，每个请求用独立 stream，别复用
每个 OpenDownloadStream 返回的是独立可读流（*gridfs.DownloadStream），但它底层共享连接池。如果单个 HTTP 请求里并发开 5 个 stream 下载同一文件的不同 range，MongoDB 很可能触发连接数限制或 socket 超时——尤其部署在远端云数据库时。
- 错误模式：一个 handler 里起 goroutine 并发调多次
OpenDownloadStream→ 连接打满、查询排队、慢日志暴涨 - 推荐做法：单次请求只开一个 stream，用
io.CopyN或分段Read控制读取节奏；真要并行，应在客户端拆请求，服务端保持单流 - 务必设超时：
ctx, cancel := context.WithTimeout(r.Context(), 30*time.Second)，传给OpenDownloadStream，避免慢连接长期占资源
性能崩了？先查 fs.files 和 fs.chunks 的索引
下载接口变慢，90% 是索引缺失导致全表扫描。MongoDB 日志里反复出现 slow query on fs.chunks 或 executionStats.totalDocsExamined >> nReturned 就是铁证。
-
fs.files至少要有：{ filename: 1, uploadDate: -1 }（按名+时间查）或{ "metadata.projectId": 1 }（按业务字段查） -
fs.chunks必须有：{ files_id: 1, n: 1 }—— 这是 GridFS 查询 chunk 的黄金索引，缺了就会扫整个 chunks 集合 - 建索引命令示例：
db.fs.files.createIndex({ filename: 1, uploadDate: -1 })、db.fs.chunks.createIndex({ files_id: 1, n: 1 }) - 别依赖驱动“自动建索引”：它只在 bucket 空时建，默认索引只有
_id，业务字段索引得你手动补
真正难调的是索引和 range 的组合效果——比如加了 filename 索引，但没传 uploadDate 范围，还是可能扫大量文档。上线前务必用 .explain("executionStats") 验证查询计划。
