gridfs本身不提供跨副本集一致性保障，依赖mongodb副本集的writeconcern和readconcern机制；上传后能否立即从secondary读取取决于w和readconcern配置，而非gridfs自身逻辑。
GridFS 本身不提供跨副本集的一致性保障，它依赖底层 MongoDB 副本集的写关注（writeConcern）和读关注（readConcern）机制来控制一致性行为。你上传一个文件后能否立刻从 secondary 读到，取决于你配置的 w 和 readConcern，而不是 GridFS 自身逻辑。
GridFS 写入时如何触发副本集一致性检查
GridFS 的 openUploadStream() 或 uploadFromStream() 最终会向 fs.files 和 fs.chunks 两个集合写入文档。这些写操作受客户端设置的 writeConcern 控制：
- 默认是
w: 1，即只等 primary 确认，secondary 可能还没同步完就返回成功 - 若设为
w: "majority"，则必须等多数节点（含 primary）持久化 chunk 和 file 元数据后才返回，避免读到“半上传”状态 - 注意：
fs.files和fs.chunks是两个独立集合，MongoDB 不保证它们的原子跨集合写入——除非你显式用事务包裹整个上传流程（但官方不推荐，因事务有 60 秒限制且 chunk 数量多时易超时）
从 secondary 读取 GridFS 文件时的一致性风险
直接调用 openDownloadStream() 时，驱动默认走 readPreference: primary。但如果配置了 readPreference: secondary，就可能遇到以下问题：
- 刚上传完文件，secondary 还没收到全部
fs.chunks，openDownloadStream()会报FileNotFound或读出损坏内容 - 即使
fs.files已同步，fs.chunks同步滞后，导致部分块缺失 - 解决办法是搭配
readConcern: "majority"—— 它确保你读到的是已被多数节点确认的数据，但代价是可能读不到最新写入（尤其在写入后立即读）
为什么不能靠 oplog 保证 GridFS 操作的因果一致性
GridFS 拆块写入本质是多次普通 insert 操作，每条 chunk 插入都会生成独立 oplog 条目。oplog 本身不记录“这是一个文件上传事务”的上下文，因此：
- change stream 无法把多个 chunk + file 文档聚合成一个逻辑事件
- secondary 落后时，可能先看到部分 chunk，再看到
fs.files，顺序错乱 - 没有类似 MySQL GTID 的全局有序标识，无法做精确位点回放或强一致订阅
真正要实现强一致读写，得在应用层控制：上传后显式等待 db.runCommand({ waitForWrite: { w: "majority", wtimeout: 5000 } })（或等对应 writeResult），再切换读请求到 secondary；否则，默认配置下 GridFS 在副本集中就是最终一致性模型，不是强一致。
