GridFS写操作不继承集合级writeConcern，必须在bucket实例化时显式设置w:"majority"和j:true，否则默认w:1导致元数据存在但chunk丢失；files和chunks集合需各自满足多数确认，j:true确保刷盘防崩溃丢失。
GridFS 写操作不继承集合级 writeConcern，必须在 bucket 实例化时显式设置 w: "majority" 和 j: true，否则默认仍是 w: 1 —— 这是强一致性失效的最常见原因。
为什么 setCollectionWriteConcern 不起作用
很多人给 db.collection("fs.files") 或整个数据库设了 write_concern: {w: "majority", j: true}，但 GridFS 上传依然只走 w: 1。这是因为 GridFS 是独立抽象层，驱动（PyMongo/Node.js Driver）调用 upload_from_stream() 时，不会自动透传上级配置。
-
gridfs.GridFSBucket构造时未传write_concern参数 → 所有写入（files插入 + 每个chunks插入）都按驱动默认w: 1执行 - 即使副本集已配置
members[n].priority = 1，w: "majority"仍需明确声明，否则 MongoDB 不会校验节点数 - 错误示例：
bucket = GridFSBucket(db)→ 元数据和分块都只等主节点确认，主节点宕机即丢数据
majority 对 files 和 chunks 是分别生效的
w: "majority" 不是对“一次 upload”做原子性保证，而是对 files 集合的元数据插入、以及每个 chunks 文档的插入，各自独立应用 writeConcern。
- 可能出现
files成功落 majority，但某个chunk只写到主节点就返回 → 文件元数据存在，但download()报Corrupted download: chunk size mismatch或读取截断 -
j: true的作用不是增强复制，而是确保每次写入（含每个 chunk）都刷盘到 journal，防掉电丢失；它不解决跨节点同步延迟 - 若业务要求绝对强一致（如医疗影像），不能只依赖 writeConcern 返回成功，必须后续用
read_concern: "majority"校验 chunk 数量与length字段是否匹配
PyMongo 和 Node.js 的正确写法
必须在创建 bucket 实例时绑定 writeConcern，且参数需同时覆盖 files 和 chunks 两个底层集合。
- 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 } }) - 不要复用同一 bucket 实例跨数据库操作；不同租户或场景建议用不同
bucketName（如"uploads_q3"），避免 writeConcern 配置污染 - chunkSizeBytes 不影响 writeConcern 行为，但会影响 chunk 插入频次——设为
256 * 1024（256KB）是实测吞吐与 journal 压力的平衡点
真正容易被忽略的是：writeConcern 生效的前提是副本集成员数 ≥ 3 且多数节点在线。如果只有 2 个节点，w: "majority" 等价于 w: 2，而当其中一节点失联，写入会直接超时失败 —— 这不是配置错，而是架构硬约束。
