gridfs 默认不继承数据库或集合的 writeconcern，必须显式配置 writeconcern(w="majority", j=true) 才能保障 files 和 chunks 集合写入的强一致性与持久化；否则默认 w:1 易导致元数据存在但内容丢失。
GridFS 默认不继承集合或数据库的 writeConcern，必须在创建 GridFSBucket 实例时显式传入 write_concern=WriteConcern(w="majority", j=True)，否则上传成功 ≠ 数据已强一致。
GridFS 的 writeConcern 不会自动继承上级配置
很多人给 db 或 collection 设置了 write_concern={"w": "majority"}，就以为 GridFS 也生效了——实际完全无效。GridFS 是独立抽象层，底层操作的是 files 和 chunks 两个固定命名集合，驱动（如 PyMongo、Node.js Driver、Go Driver）在调用 upload_from_stream() 或 open_upload_stream() 时，根本不会读取父级配置。
后果很直接：默认仍是 w: 1，只等主节点内存写入就返回。主节点若崩溃且未同步，刚上传的文件元数据或任意一个 chunk 都可能丢失，导致 find() 能查到文件但 download() 报错或内容截断。
实操建议：
- PyMongo 中必须显式构造 bucket：
bucket = gridfs.GridFSBucket(db, write_concern=WriteConcern(w="majority", j=True)) - Node.js Driver 同理：
new GridFSBucket(db, { writeConcern: { w: "majority", j: true } }) - Go Driver 使用
options.GridFSBucket().SetWriteConcern(writeconcern.Majority().Journaled()) - 不要在 upload 过程中动态改 writeConcern，它只在 bucket 初始化时绑定一次
“majority” 对 GridFS 意味着 files + chunks 双集合各自满足
GridFS 一次上传会拆成两步：先写 files 集合存元数据，再把文件分块写入 chunks 集合。设置 w: "majority" 并不是对“整个文件操作”做原子性保证，而是分别对每次写入应用 writeConcern——files 插入要落 majority，每个 chunks 文档插入也各自要落 majority。
这带来两个关键事实：
- 如果
files成功落 majority，但某个chunk因网络抖动只写到主节点就返回，而主节点随后宕机，该文件将元数据存在、内容残缺 - 不能仅靠
upload_from_stream()返回成功，就认为文件已强一致；业务敏感场景需额外校验，比如上传后立即用read_concern="majority"读取并比对length和chunkSize字段 - 事务不适用于 GridFS 操作（GridFS 本身不支持事务），所以无法靠事务包裹 files + chunks 来规避这个问题
j: true 不是锦上添花，而是防崩溃丢失的必要条件
w: "majority" 只保证写入多数节点的内存 oplog，不保证刷盘。如果节点因 kill -9、断电或 OOM 崩溃，而 journal 未启用或 j: false，那这部分数据就永久丢失——从节点同步的也是不稳定的内存数据。
所以 j: true 必须配合 w: "majority" 使用，它强制每个写入（包括 files 插入和每个 chunk 插入）都等待 journal 持久化完成。注意两点：
- 服务端 journal 必须开启（MongoDB 默认开启，但单机部署或旧配置可能关闭，可用
db.runCommand({getCmdLineOpts: 1})检查storage.journal.enabled） -
wtimeout是必设项，例如wtimeout: 5000；否则网络分区或某从节点卡住时，上传会无限阻塞，拖垮连接池 -
wtimeout只对w > 1或w: "majority"生效，w: 1下无效
生产环境必须验证 majority 节点是否真实在线
副本集配置里的 members[n].votes > 0 成员才参与 majority 计算，但隐藏节点（hidden: true）、延迟节点（slaveDelay > 0）默认不计入——除非你显式设 votes: 1。更危险的是仲裁节点（Arbiter）：它有 votes: 1 但不存数据，能凑数达成 majority，却无法提供数据冗余。
跨地域部署时更要小心：比如北京 2 节点 + 广州 2 节点 + 上海 1 节点，理论 majority = 3，但若广州机房整体失联，剩下 3 节点虽够数，广州 Secondary 的 oplog 同步会停滞，恢复后需全量同步而非增量追赶。
真正可靠的判断方式是运行 rs.status().members，看各节点的 health === 1 且 stateStr === "SECONDARY"（或 "PRIMARY"），别只信 rs.conf() 里写的 votes 数。
