gridfsbucket初始化必须显式设置writeconcern为"majority"和j:true，否则默认w:1导致元数据存在但chunk丢失；files和chunks集合需各自满足多数确认，j:true确保刷盘防崩溃丢失。
GridFSBucket初始化时必须显式传write_concern
GridFS 不继承数据库或集合的 write_concern，哪怕你对 db 或 db.fs.files 调用了 with_options(write_concern=...)，上传操作依然走默认 w: 1。PyMongo 的 gridfs.GridFSBucket 构造函数不读取上级配置，只认自己参数里的 write_concern。
常见错误是写成：bucket = gridfs.GridFSBucket(db) → 所有 files 插入和每个 chunks 插入都只等主节点内存写入就返回，主节点宕机即丢 chunk。
正确做法是：
- PyMongo：
bucket = gridfs.GridFSBucket(db, write_concern=WriteConcern(w="majority", j=True)) - Node.js Driver：
const bucket = new GridFSBucket(db, { writeConcern: { w: "majority", j: true } }) - Go Driver：
options.GridFSBucket().SetWriteConcern(writeconcern.Majority().Journaled())
w: "majority" 对 files 和 chunks 是分别生效的
GridFS 一次上传会拆成两阶段：先插入 fs.files 元数据，再逐个插入 fs.chunks 文档。设置 w: "majority" 并不是对“整个文件”做原子性确认，而是对每次底层写入单独应用 writeConcern。
这意味着：
-
fs.files插入成功落 majority，不代表任意一个chunk也落了 majority - 可能出现元数据存在、但某个
chunk只写到主节点就返回 → 下载时报Corrupted download: chunk size mismatch或内容截断 - 不能仅靠
upload_from_stream()返回成功就认为文件已强一致
业务敏感场景（如医疗影像）需额外校验：上传后立即用 read_concern="majority" 查询 fs.files 和 fs.chunks，比对 length 字段与实际 chunk 数量是否匹配。
j: true 不是可选项，是防崩溃丢失的必要条件
j: true 的作用不是加速复制，也不是增强一致性级别，而是强制每次写入（含每个 chunk 插入）都刷盘到 journal 日志。没有它，即使 w: "majority" 满足，节点掉电或硬重启仍可能丢失刚确认的 chunk。
注意：
-
j: true会增加写延迟，但在副本集部署中不可省略 - 它不解决跨节点同步延迟问题，只解决单节点持久化问题
- 若 MongoDB 部署未启用 journal（如某些旧版或误配实例），
j: true会直接报错或静默降级
read_concern="majority" 必须在读取时显式传入
上传时用了 w: "majority" + j: true，不代表后续读取就能看到已提交数据。MongoDB 默认 read_concern 是 "local"，即可能读到未同步到多数节点的中间状态。
要确保读取的是已多数确认的数据，必须在查询时显式指定：
- PyMongo：
bucket.find({}, read_concern=ReadConcern("majority")) - Node.js：
bucket.find({}, { readConcern: { level: "majority" } })
这个配置不会自动继承自 GridFSBucket 实例，也不能靠客户端全局设置覆盖——GridFS 的读操作由驱动内部发起，必须在每个读调用中透传。
真正容易被忽略的是：read_concern="majority" 要求 MongoDB ≥ 3.2 + WiredTiger 引擎 + 副本集模式，三者缺一不可；否则会静默退回到 "local"。
