GridFS不支持多文档事务，因其文件元数据写入fs.files与数据块写入fs.chunks分属两个集合且操作不可原子化；官方明确禁止在事务中调用GridFSBucket方法，正确做法是先上传再用事务关联业务状态。
GridFS 本身不支持多文档事务，fs.files 和 fs.chunks 的写入无法被包裹进同一个 MongoDB 事务中。这意味着：你不能在单个事务里「同时提交文件块 + 更新元数据文档」并保证原子性。
为什么 GridFS 无法参与事务
MongoDB 的事务只作用于单个副本集或分片集群中的数据文档，但 GridFS 的底层操作会跨两个集合（fs.files 和 fs.chunks）写入，并且 GridFSBucket 的 openUploadStream() 内部使用的是非事务性写入流 —— 它先插入 fs.files 文档获取 _id，再以该 _id 为 files_id 分批写入 fs.chunks。这个过程无法被 session.startTransaction() 拦截或回滚。
- 官方明确说明：
GridFS does not support multi-document transactions - 即使你在事务 session 中手动调用
bucket.openUploadStream()，驱动也不会将其纳入事务上下文 -
fs.chunks插入失败时，fs.files文档已存在，形成“孤儿元数据”
替代方案：用独立事务管理元数据，而非 GridFS 流程
如果你需要「上传成功后立即关联业务状态」（比如订单附件、用户头像绑定），正确的做法是：把真正需要原子性的逻辑从 GridFS 操作中剥离出来，单独用事务维护业务文档与 fs.files._id 的关系。
- 先用
bucket.openUploadStream()上传文件，拿到返回的ObjectId（来自fs.files._id） - 再在事务中执行业务操作，例如：
updateOne({ _id: orderId }, { $set: { avatarId: fileId } }) - 如果事务失败，
fs.files和fs.chunks仍残留，但业务侧未确认关联，可后续通过定时任务清理孤立文件 - 不要尝试在事务里调用
bucket.uploadFromStream()或任何GridFSBucket方法
如何安全清理上传中断产生的孤儿文件
上传异常（网络断开、进程崩溃）可能导致 fs.files 已写入但 fs.chunks 不完整，这类文件无法被正常读取，需主动识别并删除。
- 查询所有在
fs.files中存在、但在fs.chunks中无对应files_id的文档：db.fs.files.aggregate([ { $lookup: { from: "fs.chunks", localField: "_id", foreignField: "files_id", as: "chunks" } }, { $match: { "chunks.0": { $exists: false } } } ]) - 确认后执行清理：
db.fs.files.deleteMany({ _id: { $in: [ /* 上述查出的 _id 数组 */ ] } }) - 注意：不要直接删
fs.chunks，MongoDB 驱动不保证 chunk 写入顺序或完整性校验，必须依赖files_id关联性判断
真正容易被忽略的是：开发者常试图用事务“兜住”整个上传流程，但 GridFS 的设计决定了它和事务是互斥的。重点应放在上传后的业务一致性上，而不是上传过程本身 —— 后者靠重试、幂等名、断点续传更实际，前者才适合事务兜底。
