事务失败时须捕获TransientTransactionError并重试，非核心操作应剥离事务；降级需基于实时指标（如错误率>5%或P99延迟超800ms），并强制回收session资源。
MongoDB 生产环境事务不能简单“降级为普通写入”，必须明确：事务失败时，应用层要能识别 TransientTransactionError 并执行完整重试逻辑；而真正需要降级的，是那些本不该进事务的读操作、日志记录、缓存更新等非核心路径——它们应从一开始就剥离出事务上下文。
事务失败时必须捕获 TransientTransactionError 而非泛化异常
MongoDB 驱动对事务错误做了精细分类：TransientTransactionError 表示可重试（如主节点切换、网络抖动），UnknownTransactionCommitResult 表示提交结果未知但可能已生效，NoSuchTransaction 等则不可重试。若只用 Exception 或 RuntimeException 捕获，会把可重试错误当致命故障处理，导致数据不一致。
- PyMongo 示例中必须显式检查：
if isinstance(e, pymongo.errors.TransientTransactionError) - Java Driver 中需用
e instanceof MongoTransientTransactionException，不能依赖MongoWriteException父类 - Spring Data MongoDB 6.2+ 提供了
@RetryableTransaction注解，但底层仍依赖驱动抛出的原生异常类型，配置前务必验证实际抛出类名
非事务路径不能塞进同一 session，否则拖垮整个事务生命周期
常见错误是把日志写入、Redis 缓存更新、消息队列投递等操作，和核心业务逻辑一起放进同一个 with_transaction() 块。这些操作本身不参与原子性保障，却因失败导致整个事务回滚或重试，放大故障面。
- 日志记录必须走独立连接（如
MongoClient.getDatabase("logs").getCollection("app_events")），禁用事务 session - 缓存更新建议改用最终一致性方案：事务提交成功后，再异步触发缓存刷新（如发 Kafka 事件），避免阻塞
- 若必须同步更新缓存，使用
try/finally+session.startTransaction()后手动控制，但不将缓存操作纳入commitTransaction()范围
降级开关必须基于真实指标，而非静态配置
硬编码的“事务开关”在生产中极易失效：流量突增时该降级没降，低峰期不该降级却关闭了事务，反而掩盖数据问题。真正可用的降级策略应响应实时信号。
- 监控
transientTransactionError错误率（1分钟窗口 > 5% 触发降级） - 观察
transactionDurationMillisP99 超过阈值（如 800ms）且持续 3 分钟，自动暂停新事务创建 - 降级状态需广播至所有实例（如写入 Redis 的
txn:degraded:cluster_akey），避免单点判断失准 - 降级后不是停用事务，而是将非关键业务路由到只读副本或影子库，核心链路仍保事务能力
最易被忽略的是：事务 session 对象本身有资源开销，长期持有未关闭的 session 会导致连接池耗尽、oplog 堆积。降级方案里必须包含 session 生命周期强制回收机制——哪怕降级期间，也要确保每个请求的 session 在 5 秒内释放。
