gridfs写操作不继承集合级writeconcern，必须在bucket实例化时显式设置；w:"majority"要求files和chunks双集合各自满足多数节点确认，j:true确保刷盘防崩溃丢失，错误配置将使majority失效。
GridFS 写操作默认不继承集合级 writeConcern
很多人以为给 collection 设置了 writeConcern: {w: "majority"}，GridFS 就自动生效——其实不会。GridFS 是独立的抽象层，它底层用的是 chunks 和 files 两个集合，但驱动（如 PyMongo、Node.js Driver）在调用 bucket.upload_from_stream() 或 open_upload_stream() 时，并不会自动把父集合的 writeConcern 透传过去。
这意味着：即使你对数据库或集合设了全局 writeConcern，GridFS 文件上传仍可能只走 w: 1（仅主节点确认），一旦主节点宕机且未同步到从节点，刚上传的文件元数据或分块就可能丢失。
实操建议：
- 显式为 GridFS bucket 设置 writeConcern，例如 PyMongo 中：
bucket = gridfs.GridFSBucket(db, write_concern=WriteConcern(w="majority", j=True)) - Node.js Driver 同理，在
GridFSBucket构造时传入：writeConcern: { w: "majority", j: true } - 避免依赖“默认”或“上级配置”，GridFS 的 writeConcern 必须在 bucket 实例化时绑定
majority 对 GridFS 的实际约束是 files + chunks 双集合都满足
GridFS 一次文件写入会拆成两步：先写 files 集合存元数据，再分块写入 chunks 集合。当设置 w: "majority" 时，MongoDB 不会对“整个 GridFS 操作”做原子性保证，而是分别对这两个集合的每次写入应用 writeConcern。
也就是说：files 文档写入需落到 majority 节点，每个 chunks 插入也各自要满足 majority —— 二者不联动，也不事务包裹。
这带来两个关键影响：
- 如果
files成功落 majority，但某个chunk因网络抖动只落到主节点就返回，而主节点随后宕机，那该文件将“元数据存在、内容残缺”，find()能查到文件，但download()会报错或返回截断内容 - 不能靠单次
upload_from_stream()的成功返回，就认为文件已强一致；必须配合后续校验（如 checksum 对比）或读取验证 - 若业务要求绝对强一致（如医疗影像归档），需额外加一层应用层确认逻辑，比如上传后立即用
read_concern: "majority"读取并校验 chunk 数量和 size 字段
journal 开关（j:true）对 GridFS 强一致性的实际意义
j: true 并不是“让 majority 更可靠”，而是确保每个写入（包括 files 插入和每个 chunk 插入）都刷盘到 journal 日志。它解决的是“掉电/崩溃后能否恢复”的问题，而非“跨节点复制是否完成”。
在高可用场景下，j: true 是 w: "majority" 的必要补充，原因如下：
- 若只设
w: "majority"但j: false，MongoDB 可能在内存中完成复制确认后就返回，此时若主节点突然断电，尚未刷盘的 chunk 数据会丢失，导致 majority 节点中部分数据不完整 - 副本集同步依赖 oplog，而 oplog 本身受 journal 保护；journal 不刷盘，oplog 写入也可能丢失，间接影响 secondary 的数据完整性
- 生产环境强烈建议组合使用：
{w: "majority", j: true}，尤其对大文件（>10MB）分块多、写入耗时长的场景
writeConcern 设置位置错误会导致 majority 形同虚设
常见误操作是把 writeConcern 放在错误层级：比如在 db.command() 里设，或试图用 setDefaultRWConcern 覆盖 GridFS 行为——这两者对 GridFS bucket 的 upload/download 操作完全无效。
真正起效的位置只有三个，且优先级从高到低：
- GridFS bucket 实例构造时传入的
write_concern/writeConcern参数（最高优先级，推荐） - 单次 upload 方法调用时传入的
options.write_concern（如 PyMongo 的upload_from_stream(..., write_concern=...)） - 集合级 writeConcern（
db.get_collection("fs.files").write_concern = ...）——但注意：这只能影响你手动对files或chunks集合的直写，不影响 GridFS API 封装的流程
最容易被忽略的一点：Driver 版本差异。PyMongo ≥ 4.0 默认禁用 getLastError 兼容模式，旧写法（如手动调 db.command("getLastError")）不再触发 writeConcern 等待；必须用显式 writeConcern 对象绑定到 bucket 或操作上。
