MongoDB 7.0 的 GridFS 仍不支持断点续传和秒传，二者均需应用层实现；服务端未新增协议字段，仅增强稳定性与校验，如严格检查 fs.files 字段、要求显式创建哈希唯一索引等。
MongoDB 7.0 的 GridFS 本身仍不支持断点续传或秒传——这两个功能必须由应用层实现，驱动和服务器未新增相关协议或字段。所谓“7.0 支持”，其实是旧机制在新版本下更稳定、更可控，而非开箱即用。
为什么 MongoDB 7.0 没有内置断点续传
GridFS 规范（截至 2026 年）仍未定义上传状态、chunk 确认应答、分片校验或临时文件标识等语义。MongoDB 7.0 的 mongod 进程依然按原始逻辑处理 fs.chunks 插入：只校验 files_id 和 n 字段合法性，不检查是否“已传一半”。断点续传依赖客户端记录已写 chunk 范围，并跳过重复写入——这一步完全在业务代码里。
常见误判点：
- 把
GridFSBucket.openUploadStream()的uploadId当作断点凭证——它只是客户端生成的 ObjectId，服务端不持久化、不校验、不查询，仅用于日志追踪 - 认为
insertOne({ files_id, n, data })失败后能自动 resume——实际需捕获E11000 duplicate key或网络错误，再查fs.chunks.countDocuments({ files_id, n: { $gte: X } })确认进度 - 并发上传同一文件时复用
uploadId，但没加分布式锁，导致多个客户端同时写相同n值，最终文件错乱
秒传在 7.0 中仍靠哈希 + 唯一索引兜底
MongoDB 7.0 对 fs.files 的写入校验更严格（如拒绝缺失 length 或 chunkSize 的文档），但没增加哈希字段自动提取或内容去重能力。秒传逻辑与旧版一致：客户端算 sha256 → 查询 fs.files.hash → 命中则返回 _id → 未命中才走上传流。
7.0 下需特别注意：
-
db.fs.files.createIndex({ hash: 1 }, { unique: true })必须显式创建，7.0 不会自动建；若漏建，重复哈希会静默插入多条元数据，导致“秒传失效” - 哈希值必须统一用小写十六进制（非 base64），否则
"A" !== "a"会导致相同文件被当成两个 - 使用 Node.js 驱动 v6.7+ 时，
GridFSBucket.find({ hash: "xxx" })返回游标，别直接.toArray()查大库——加.limit(1).project({ _id: 1 })减少内存压力
上传超时与 chunkSize 在 7.0 中的实际调优
MongoDB 7.0 默认 operationTimeoutMS 仍是 30 秒，对 GB 级文件依然不够。不能只调大客户端 timeout，必须协同修改服务端：
- 运行
db.adminCommand({ setParameter: 1, operationTimeoutMS: 300000 })（单位毫秒），该参数热生效，无需重启 -
chunkSizeBytes推荐设为2097152（2MB）：7.0 的 WiredTiger 在 2MB chunk 下压缩率与 I/O 平衡最优；设太大（如 4MB）可能触发单 chunk 写入慢日志，设太小（255KB 默认）则增加 chunks 文档数量和索引压力 - 上传前务必传
uploadId字段，并在失败后用fs.chunks.deleteMany({ files_id: uploadId })清理——7.0 不提供abortUploadAPI，脏数据只能手动删
真正容易被忽略的是：秒传和断点续传的边界条件都在客户端流控制里。比如 Node.js 中用 stream.clone() 同时喂哈希和上传流，这个操作在 7.0 驱动下必须确保流未被 pipe 过一次以上，否则 openUploadStream() 会收到空流并静默结束——问题不报错，但文件永远存不进去。
