MongoDB完全不支持嵌套事务，多次调用startTransaction仅复用同一Session，不会创建新事务上下文，第二次调用将抛出TransactionAlreadyInProgress错误。
MongoDB 事务不支持真正的嵌套，startTransaction 多次调用只是复用同一 Session
直接说结论：MongoDB 没有“嵌套事务”概念。所谓“嵌套调用 startTransaction”，实际只是在同一个 ClientSession 上反复调用该方法，它不会创建新事务上下文，也不会隔离或回滚局部操作。如果你看到代码里写了两次 startTransaction，那大概率是误用——第二次调用不会开启新事务，而是静默忽略（或在某些驱动中抛出 IllegalOperation）。
常见错误现象：
- 外层事务已
commit，但内层看似独立的update却已落库（因为根本没被事务包裹） - 调用
session2.startTransaction()后执行操作，却不受session1控制，导致写冲突或数据不一致 - 试图对两个不同
ClientSession实例分别调用startTransaction并期望它们形成父子关系——这在 MongoDB 协议层完全不成立
真正要实现“逻辑嵌套”，必须复用同一个 ClientSession 实例
业务上常说的“嵌套逻辑”，比如订单创建包含库存扣减、积分更新、日志记录，这些操作必须全部在同一个 ClientSession 下执行，否则无法保证原子性。关键不是调用几次 startTransaction，而是所有操作是否绑定到同一个 session 对象。
实操建议：
- 把
ClientSession作为参数显式传入各子函数，而不是在每个函数里自己 new 一个 session - 避免在工具类或 DAO 方法内部隐式获取新 session；检查驱动封装（如 Spring Data MongoDB 的
@Transactional）是否真的透传了 session - 确认驱动版本：MongoDB Java Driver 4.3+、Node.js Driver 4.0+ 均要求显式管理 session 生命周期；旧版可能自动创建 session 导致意外脱离事务上下文
- 使用
withTransaction辅助方法（如 Node.js Driver 提供的）可减少手动start/commit/abort的遗漏风险
并发写冲突和锁等待超时是嵌套逻辑中最容易被忽略的硬伤
当你把多个更新操作塞进一个事务，且这些操作涉及相同文档（尤其是高频更新字段），就极易触发 WriteConflict。这不是代码写错了，而是 MongoDB 事务锁机制的固有限制：它不支持乐观锁重试，一旦冲突，整个事务必须 abort 并重试。
典型场景：
使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能
- 两个请求同时执行
session.startTransaction()→ 都尝试update({a: 1}, {$inc: {counter: 1}})→ 先 commit 的成功，后 commit 的收到WriteConflict - 事务内含耗时操作（如 HTTP 调用、文件读写），导致锁持有时间过长，触发默认 60 秒的
maxTransactionLockRequestTimeoutMS - 嵌套调用中混入异步操作（如 Node.js 的
await后续未 await 完毕就进入下一个 update）→ session 状态错乱，事务提前终止
解决方向不是“怎么嵌套”，而是“怎么收缩事务边界”：把非数据库操作（日志、通知、缓存更新）移出事务块；把大事务拆成多个小事务（用幂等 + 补偿逻辑兜底）。
点号（.）字段名在事务中照样报错，和是否嵌套无关
如果嵌套逻辑里动态构造了带点号的 key（比如 {"user.profile.name": "Alice"}），哪怕在事务中执行，也会在插入/更新时直接抛 MappingException 或 InvalidFieldName。MongoDB 从底层禁止字段名含 . 和 $，事务不改变这一约束。
避坑方式：
- 字段名预检：入库前用正则
/[.$]/扫描所有 key，替换为下划线或驼峰 - 避免用用户输入直接拼接字段路径；结构化数据应通过嵌套对象而非扁平化 key 表达层级，例如用
{"user": {"profile": {"name": "Alice"}}}而非{"user.profile.name": "Alice"} - 注意 ORM 层（如 GORM）是否自动做了字段映射转换；有些驱动会把结构体字段
ProfileName映射为profile_name，但若手动指定bson:"user.profile.name"就会踩雷
事务本身不增加字段校验宽容度，该报错的地方，嵌套再深也照报不误。
