GridFS不支持跨集合原子写入，因fs.files与fs.chunks是独立集合且官方禁止在事务中调用GridFSBucket方法；writeConcern="majority"无法保证原子性，因元数据与chunk写入各自独立执行，存在“有元数据无内容”风险；需应用层通过版本标识、状态检查及分片键规范来兜底一致性。
GridFS 本身不支持跨集合原子写入
fs.files 和 fs.chunks 是两个独立集合，MongoDB 官方明确禁止在事务中调用 GridFSBucket 方法（如 openUploadStream()）。即使你手动开启 session.startTransaction()，底层驱动仍会绕过事务，直接走非事务写入路径。这不是配置问题，而是 GridFS API 的设计限制——它本质是封装好的两段式操作：先插元数据，再分块写数据，中间无事务锚点。
为什么 writeConcern = "majority" 不等于原子性
设置 write_concern=WriteConcern(w="majority", j=True) 能提升单次写入的持久性，但无法消除“元数据已落盘、部分 chunk 未同步”的风险。因为：files.insert_one() 和每个 chunks.insert_one() 是独立的写操作，各自按自己的 writeConcern 执行。若某个 chunk 插入时主节点宕机且未同步，该文件就会变成“有元数据、无内容”，openDownloadStream() 直接抛 FileNotFound。
- 默认
w:1更危险：上传返回成功，但元数据或任意 chunk 都可能丢失 -
j:True是底线要求，否则崩溃后连已确认的写入都可能回滚 - 不能只靠 upload 返回成功就认为文件可用；敏感场景需上传后立即用
read_concern="majority"校验length与实际 chunk 总字节数是否匹配
应用层必须承担一致性边界控制
放弃“数据库保证原子替换”的幻想，转而用版本标识 + 状态检查兜底：
- 每次覆盖前，用
findOne({ _id: ObjectId(...) })精确获取待替换文件的真实_id（别用filename，同名文件可能多个） - 新文件上传成功后，在其
metadata中显式写入previousVersionId: oldId - 再执行
bucket.delete(oldId)；若失败，可通过previousVersionId快速定位并恢复旧版 - 所有读请求改用带时间戳的查询，例如
{ filename: "x.pdf", uploadedDate: { $lt: new Date() } }并按uploadedDate倒序取第一条
分片集群下孤儿块风险更高
在分片集群中，fs.files 和 fs.chunks 若未按规范分片，会导致 chunk 查询被广播到所有分片（scatter-gather），大幅增加写入失败概率。必须确保：fs.chunks 以 files_id 哈希分片，且 fs.files 分片键能支撑业务查询模式（如 user_id 或 filename 哈希）。否则，一次上传可能因路由失败中断，留下孤立的 fs.chunks 文档——它们没有对应 fs.files 记录，也永远不会被自动清理。
