小程序云数据库的底层基于MongoDB，事务能力在云开发控制台开通后即可使用。开发者最常见的困惑是：明明用事务包裹了读写操作，为什么线上还是偶发写入冲突？这需要先理解云数据库在事务中的并发控制模型。
理解隔离级别与行级锁的生效范围
云数据库事务默认采用快照隔离（Snapshot Isolation）。在事务开始时，系统会为当前事务建立一个一致的数据快照，事务内的所有读操作都基于这个快照返回结果，不会看到其他事务修改后的中间状态。这种隔离级别能有效避免脏读和不可重复读，但仍然存在写偏斜（Write Skew）问题：两个事务读取了同一份数据，然后各自基于读取的结果去修改不同的记录，最终可能产生违反业务约束的结果。
写操作方面，云数据库在事务提交阶段会进行冲突检测。如果两个并发事务尝试修改同一条记录，先提交的事务会成功，后提交的事务会收到带有 DATABASE_TRANSACTION_CONFLICT 错误码的异常。需要注意的是，冲突检测发生在提交阶段，而不是执行写操作的那一刻。也就是说，即使你在事务内部已经执行了 update 语句，只要事务还没有提交，冲突就不会立刻暴露出来。
因此，不要把事务内的更新语句当成“已经生效”。正确的做法是收集所有写操作，在事务接近尾声时统一提交，并用 try/catch 捕获提交阶段抛出的冲突异常。
常见并发冲突场景与处理策略
第一种常见场景是多个用户同时扣减库存。假设商品详情页展示剩余库存为10，用户A和用户B几乎同时点击购买。两个事务都读到库存为10，然后各自执行库存减1操作。按照快照隔离的规则，两个事务修改的是同一条记录，提交时只能有一个成功，另一个会触发冲突。此时如果简单粗暴地把错误抛给用户，体验会很差。
推荐的第一种策略是捕获冲突后自动重试。云开发提供了 runTransaction 方法，该方法内部封装了自动重试逻辑，但默认重试次数有限。你也可以手动实现重试循环，例如在 catch 块中判断错误码是否为 DATABASE_TRANSACTION_CONFLICT，如果是则重新执行整个事务函数。重试次数建议控制在3次以内，每次重试之间可以加入随机延迟，避免多个客户端同时重试再次碰撞。
第二种策略是引入版本号做乐观锁。在商品文档中增加一个 version 字段，事务开始时读取当前版本号，更新库存时把条件写成 where({ _id: productId, version: oldVersion }).update({ data: { stock: _.inc(-1), version: _.inc(1) } })。如果在这期间有其他事务已经修改了版本号，那么条件不匹配，更新影响的行数为0，开发者可以据此判断冲突并重新读取数据。这种方案比依赖事务本身的冲突检测更轻量，特别适合读多写少、冲突概率较低的场景。
第三种场景是重复提交问题。例如用户快速点击两次支付按钮，两个事务都执行了扣款操作。由于这两次操作在业务上属于同一次请求，只应该成功一次。单纯靠事务无法解决重复提交，需要给请求生成一个唯一的幂等键。可以在订单文档上建立唯一索引，把幂等键写入文档，第二个事务尝试插入相同幂等键时会因为唯一索引冲突而失败，从而保证只有第一次提交能成功。
事务重试与幂等性设计的落地细节
手动实现事务重试时，整个事务函数必须是无副作用的，也就是在执行事务之前不要修改外部状态。云数据库的 db.runTransaction 接受一个回调函数，该回调内部的所有数据库读写操作都会被视为事务的一部分。重试时，这个回调会被重新调用一次，因此回调内不应该包含发送短信、调用第三方API等非事务性动作，否则重试会导致这些动作被执行多次。
下面是一段完整的库存扣减事务示例，包含了冲突重试和幂等键检查：
const cloud = require('wx-server-sdk')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })
const db = cloud.database()
async function deductStock(productId, userId, idempotencyKey) {
const MAX_RETRY = 3
for (let attempt = 0; attempt < MAX_RETRY; attempt++) {
try {
await db.runTransaction(async transaction => {
const productRes = await transaction.collection('products')
.doc(productId)
.get()
const product = productRes.data
if (product.stock <= 0) {
throw new Error('INSUFFICIENT_STOCK')
}
// 幂等键检查：如果该订单已经存在，说明已经扣减过，直接返回
const existingOrder = await transaction.collection('orders')
.where({ idempotencyKey })
.get()
if (existingOrder.data.length > 0) {
return
}
await transaction.collection('products')
.doc(productId)
.update({
data: { stock: _.inc(-1) }
})
await transaction.collection('orders')
.add({
data: {
productId,
userId,
idempotencyKey,
createdAt: db.serverDate()
}
})
})
return // 事务成功，跳出重试循环
} catch (err) {
if (err.code === 'DATABASE_TRANSACTION_CONFLICT' && attempt < MAX_RETRY - 1) {
await new Promise(resolve => setTimeout(resolve, 100 * (attempt + 1)))
continue
}
throw err
}
}
}
这段代码里，transaction.collection('orders').add 使用事务对象执行插入，保证插入操作也参与事务。幂等键查询放在事务内部，利用快照隔离的读一致性，避免两个并发事务同时查到不存在幂等键然后都执行插入。但要注意，快照隔离下两个事务可能都读不到对方的未提交数据，此时仍然可能同时进入插入分支。为了彻底防止重复插入，还需要在订单集合上针对 idempotencyKey 字段创建唯一索引。唯一索引属于数据库层面的强约束，即使事务冲突检测漏掉，插入阶段也会触发唯一键冲突错误。
重试时的随机延迟可以使用指数退避算法。示例中采用的是固定线性延迟，生产环境建议引入随机因子，例如 setTimeout(resolve, 100 * 2 ** attempt + Math.random() * 50)，避免多个客户端同时重试导致惊群效应。重试次数不宜过多，因为云数据库单个事务的执行时间有限，多次重试可能累积超过整体超时时间。
性能优化与避免长事务的工程实践
云数据库事务有默认的超时时间，超过这个时间事务会被自动回滚。因此，开发时应把事务范围控制得尽可能小。所有可以在事务外完成的操作，比如读取配置、解析参数、调用外部API，都应该放在 runTransaction 回调之外。事务内部只保留最小集合的数据库读和写操作。
一个常见的反模式是在事务循环中查询大量文档。例如遍历购物车条目，在事务内逐条查询商品信息，再逐条更新库存。当购物车商品数量较多时，事务执行时间会显著拉长，冲突概率也随之上升。更好的做法是先用普通查询（非事务）一次性取出所有商品信息，然后只把更新库存的写操作放在事务内，并且尽量合并写操作。云数据库支持 where 条件批量更新，可以减少事务内语句数量。
另一个需要注意的点是读操作的时机。快照隔离下事务内的读操作不会加锁，只有写操作才会在提交时检测冲突。因此，如果你的业务逻辑是“读一条数据，然后根据读取结果决定是否写入”，需要意识到读取的数据可能在事务执行期间已经被其他事务修改。如果业务上无法接受这种不一致，建议在写操作时带上更严格的条件，比如使用乐观锁版本号，或者在事务内使用 doc().get() 之后立即执行一个无意义的写操作来触发冲突检测，但这种方式会增加复杂度，并不推荐。
对于写入频率极高的热点数据，例如秒杀场景下的库存扣减，单纯依赖云数据库事务可能成为瓶颈。此时可以考虑引入消息队列异步化，将扣减请求排队处理，或者使用云函数内的内存计数器结合定期持久化。小程序云开发生态中，云函数可以作为轻量级的串行处理单元，将热点数据的并发写入收敛到单个实例上，从而绕开数据库事务的冲突开销。
最后提醒一点，云数据库事务的回滚是自动的，不需要手动调用 rollback。任何在事务回调内抛出的异常都会导致整个事务回滚，所有已执行的写操作都不会生效。但要注意，如果你在事务内使用了 update 命令的 _.inc 这类原子操作，回滚同样会撤销这些原子操作的结果，因此不要担心回滚后计数不准确的问题。