MongoDB 7.0 中 GridFS 不支持事务。因其驱动将 uploadFromStream 等操作拆分为多次写入 fs.files 和 fs.chunks，且显式禁用事务上下文；替代方案需手动用底层集合+显式事务实现原子写入，但丧失流式处理能力且读取仍非强一致。
MongoDB 7.0 中 GridFS 是否支持事务
不支持。GridFS 本身不是原子操作层，它只是基于 fs.files 和 fs.chunks 两个集合的客户端封装协议；即使 MongoDB 7.0 全面支持多文档事务，GridFS 的 uploadFromStream、downloadToStream 等方法在驱动层面仍会拆成多次写入（先插 files 文档，再分块写 chunks），这些操作无法被包裹进单个事务。
为什么不能在 Session 中对 GridFS 操作加事务控制
根本原因在于：GridFS 驱动（如 Node.js 的 mongodb v6+）在调用 uploadFromStream 时，内部会显式结束当前 session（如果传入了 session），并禁用事务上下文——这是为了防止 chunk 写入失败导致事务长时间挂起或超时。你可以验证这一点：
const bucket = new GridFSBucket(db, { bucketName: 'photos' });
await bucket.uploadFromStream('cat.jpg', readable, {
session // 传了也没用，驱动会忽略
});
常见错误现象包括：
A powerful memory management system powered by ReMe that provides persistent cross-session memory, automatic user preference application, and intelligent context compression for OpenClaw.
下载
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
-
Transaction numbers are only allowed on a session that has an active transaction（当你手动在 session 里调uploadFromStream时） - 事务提交后，
fs.files有记录但fs.chunks缺失部分块（说明中间出错且未回滚）
替代方案：如何安全实现“多文件原子性”语义
如果你需要“上传 3 个文件，要么全成功、要么全失败”，必须绕过 GridFS 自动流程，改用底层集合操作 + 显式事务：
- 手动构造
fs.files文档（含_id、filename、length、chunkSize、uploadDate等字段） - 将文件内容按
chunkSize切片，生成带files_id和n序号的fs.chunks文档数组 - 在同一个
session.startTransaction()中，批量插入所有fs.files和对应fs.chunks文档（注意顺序：先files，再chunks） - 务必校验每个 chunk 的
files_id引用存在且类型匹配（ObjectId）
性能影响明显：失去流式处理能力，内存占用随文件大小线性上升；兼容性上，你写的逻辑需严格对齐 GridFS 规范（比如 n 从 0 开始、data 字段必须是 BinData）。
容易被忽略的关键点
即便你手动实现了事务化写入，MongoDB 不保证 fs.chunks 的读取一致性——例如并发下载时，可能读到只写了一半的 chunk 序列。GridFS 的“最终一致性”设计没变，事务只管写入阶段。另外，delete 操作同样无法事务化（deleteOne 在 fs.files 上触发，但驱动异步删 fs.chunks），所以“上传+删除旧版本”这类组合操作，必须自己实现两阶段清理逻辑。
