GridFS本身不支持用skip/limit实现断点续传，因其按文档数跳而非字节数跳，无法对齐chunk边界且破坏数据完整性；唯一合法方式是通过open_download_stream（指定start/end字节范围）由驱动自动定位、校验并读取。
GridFS 本身不提供 skip 和 limit 接口来实现断点续传，强行用它们模拟字节偏移会破坏数据完整性，且无法跳过 chunk 边界——这是典型误用。
为什么不能用 skip/limit 操作 chunks 集合
很多人看到 fs.chunks 是个普通集合，就试图用 find().skip(n).limit(1) 手动拼 chunk，这会导致：
-
skip按文档数跳，不是按字节数跳；一个 chunk 文档可能含 255KB 数据，也可能只含几字节（如最后一个 chunk），skip(10)不等于“跳过前 2.5MB” - chunk 文档的
n字段虽有序，但驱动不保证插入顺序严格单调（尤其并发上传、重试时），skip可能跳过空洞或重复块 - 完全绕过
files集合里的length、uploadDate、md5等元数据，后续校验、删除、查询 filename 都失效 - 手动拼接时若漏掉某个 chunk 或顺序错乱，文件解码直接失败，且无任何错误提示
open_download_stream 才是唯一合法的断点入口
所有官方驱动（PyMongo、Node.js、Java）都只通过 open_download_stream 支持字节级随机读取，它内部自动处理 chunk 定位、边界对齐和校验。关键参数只有两个：
-
start：起始字节位置（含），从 0 开始计数 -
end：结束字节位置（不含），即读取区间为[start, end)
示例（PyMongo）：
bucket = GridFSBucket(db) stream = bucket.open_download_stream(file_id, start=1024*1024, end=1024*1024+8192)
这段代码准确读取第 1MB 起的 8KB，驱动会自动定位到对应 chunk、跳过前面字节、截断末尾多余部分——你不用管 chunk 大小或 n 值。
客户端断点续传需配合 HTTP Range 实现
MongoDB 不解析 HTTP Header，所以服务端必须自己解析 Range: bytes=1000-2000，再转成 start=1000, end=2001 传给 open_download_stream。注意：
- 如果客户端请求
Range: bytes=1000-（无 end），end参数要省略，否则驱动会读到文件末尾 - 响应头必须返回
Content-Range和206 Partial Content，否则浏览器不会继续发后续 Range 请求 - 别在同一个
stream对象上反复调用open_download_stream—— 每次都要新建 stream，否则内部 buffer 和 cursor 状态会混乱
并发下载多个 Range 时的连接复用陷阱
高频场景如视频拖拽、多线程下载，容易踩的坑是：
- 用同一个
GridFSBucket实例并发开 10 个 stream，底层 MongoDB 连接池可能被占满，尤其当maxPoolSize默认为 100 且其他业务也在用时 - 未 await
stream.read()或未正确处理流结束事件，导致 socket 泄露，表现为后续请求超时或ConnectionResetError - 老版本 PyMongo（open_download_stream 返回的是异步 stream 却没用
await，会静默丢数据，末尾几 KB 总是缺失
真正需要关注的不是怎么跳过多少 chunk，而是如何让每次 open_download_stream 调用都干净、独立、带明确字节边界——其余逻辑 MongoDB 驱动已经封装好了，别绕过去。
