MongoDB 4.0+事务提交非幂等，commitTransaction不可重试；必须用\_id或业务唯一键+唯一索引+insertOne实现幂等，核心是将事务执行状态持久化为可原子校验的锚点文档。
MongoDB 4.0+ 的多文档事务本身不提供幂等提交能力，必须靠应用层配合 _id 或业务唯一键 + 唯一索引 + insertOne 的原子性来拦截重复提交。
为什么 commitTransaction 不能重试？
MongoDB 的事务提交（commitTransaction）不是幂等操作：若网络超时导致客户端收不到响应，但服务端其实已成功提交，此时重试调用会抛出 NoSuchTransaction 或 InvalidTransactionOperation 错误——这不是“重试失败”，而是“事务状态已终结，无法二次提交”。你无法靠捕获错误类型来安全判断结果。
- 服务端事务 ID 仅在活跃期间有效，提交/中止后即销毁
-
commitTransaction没有类似 HTTP 的 idempotency key 机制 - 即使开启 retryWrites=true，它只对单条写命令生效，不覆盖事务提交
用 insertOne 插入带业务唯一键的“事务锚点”
核心思路：把“事务是否已执行”这个状态，持久化为一条可原子校验的文档。常见做法是插入一条含业务唯一标识（如 order_id、payment_intent_id）的锚点文档，并确保该字段有唯一索引。
- 在事务开始前，先尝试
insertOne({ _id: "tx-abc123", order_id: "ORD-789", status: "pending", ts: new Date() }) - 若插入成功（
acknowledged: true），说明这是首次提交，继续执行后续事务操作 - 若报错
E11000 duplicate key，说明该事务已存在，直接跳过事务体，读取原status判断是否成功 - 事务体中所有修改都关联这个
_id或order_id，便于后续幂等查询
示例（Node.js + MongoDB Driver）：
const session = client.startSession();
try {
await session.withTransaction(async () => {
const anchor = { _id: `tx-${intentId}`, order_id: intentId, status: "pending" };
const result = await anchors.insertOne(anchor, { session });
if (!result.acknowledged) throw new Error("anchor insert failed");
// 执行真实业务逻辑（扣库存、建订单、发消息等）
await orders.insertOne({ order_id: intentId, ... }, { session });
await inventory.updateOne({ sku: "A123" }, { $inc: { stock: -1 } }, { session });
await anchors.updateOne({ _id: anchor._id }, { $set: { status: "committed", ts: new Date() } }, { session });
});
} catch (err) {
if (err.code === 11000 && err.errmsg.includes("duplicate key")) {
// 幂等路径：查 anchor.status 决定后续动作
const existing = await anchors.findOne({ _id: `tx-${intentId}` });
if (existing.status === "committed") return "already done";
}
throw err;
}
注意 retryWrites 和 readConcern 的实际作用边界
retryWrites=true 只对单条写命令（如 updateOne、deleteMany）在网络中断时自动重放，但它不会帮你避免事务级重复；而 readConcern: "snapshot" 是事务内一致性保障，和幂等性无关。
- 不要依赖
retryWrites来“修复”事务重试逻辑 - 事务内所有读操作必须用
session，否则可能读到未提交或过期状态 - 唯一索引必须建在分片集合的
shard key上，否则跨分片唯一性不保证（除非使用zone或哈希分片约束）
真正难的不是写几行代码，而是把“哪一步才算事务完成”的语义，精准映射到一条可原子判断的数据库状态上。多数人卡在设计锚点文档的生命周期和清理策略——比如失败事务的 pending 锚点要不要自动过期、谁来清理、清理窗口是否影响幂等判定。这些细节不落地，幂等就只是纸面逻辑。
