gridfs支持断点续传，依赖其分块存储机制：文件被切分为固定大小chunk（默认255kb），中断后已传chunk不丢失，服务端通过查询fs.chunks中指定files_id的最大n值确定续传起始位置（n从0开始），前端据此补传缺失块。
支持，但不是开箱即用的“自动断点续传”，而是靠 GridFS 的分块存储机制 + 应用层配合实现的。
为什么 GridFS 天然适合断点续传
GridFS 把文件切分成固定大小的 chunk（默认 255KB），每个块独立存入 fs.chunks 集合，元数据存在 fs.files。这意味着：上传中断后，已写入的 chunk 不会丢失，下次只需校验哪些 n（块索引）缺失，再补传即可。
- 不依赖客户端“暂停/恢复”按钮，本质是幂等块上传
- 服务端无需额外状态表记录进度，chunk 的
files_id+n组合就是唯一标识 - 但 MongoDB 本身不提供“续传接口”，得自己查
fs.chunks判断缺哪些块
fs.chunks 查询缺块的实操方式
客户端上传前先发个请求问：“这个 fileId 已经传了几块？” 服务端查 fs.chunks 中该 files_id 下最大的 n 值，返回给前端作为起始位置。
- 查询语句示例：
db.fs.chunks.find({ files_id: ObjectId("...") }, { n: 1 }).sort({ n: -1 }).limit(1) - 注意：
n从 0 开始编号，若返回{ n: 4 }，说明第 0~4 块已存在，下次应从第 5 块（n=5）开始传 - 别直接 count 总数——因为 chunk 可能被部分写入失败而残留脏数据，按最大
n更可靠
Laravel-MongoDB 或 Mongoose 中容易踩的坑
很多封装库（如 laravel-mongodb 的 GridFSAdapter）只暴露了完整上传/下载方法，没暴露 chunk 级操作入口，强行续传时容易误删或重复写。
- 别调用
store()或put()重传整个文件——它会新建files_id，旧 chunk 成为孤儿 - Mongoose 的
GridFSBucket提供了openUploadStreamWithId()，必须传入已有fileId才能追加 chunk；传错 ID 会导致数据错乱 - 并发上传同一文件时，多个请求同时查
max(n)再上传，可能撞块——需加轻量锁（如 Redis setnx）或让前端按顺序串行传块
真正麻烦的不是“能不能续”，而是怎么让前后端对齐块序号、校验逻辑和失败重试边界。一个没处理好的 n 偏移，就可能导致文件末尾花屏或 PDF 打不开。
