一、乐观锁解决什么：丢失更新与版本号字段
假设一个钱包余额是100元，两个请求同时读取：请求A要加50，请求B要减30。如果两者都基于旧余额计算新值并直接写回，最终余额要么是150要么是70，而正确结果应该是120。问题不是数据库写冲突，而是业务层基于过期数据做了决定。只有当更新条件里带上读取时的状态，数据库才能替我们判断这中间有没有发生过变化。版本号字段就是专门做这个判断的：每次成功更新都必须把version加一，这样任何基于旧版本的更新都会因为条件不匹配而失败。
乐观锁与悲观锁的关键区别在于：悲观锁使用SELECT FOR UPDATE或数据库行锁，在事务期间阻止其他事务修改同一行；乐观锁完全不阻塞其他请求，只在提交时检查版本号。大多数Web请求耗时很短，冲突概率不高，乐观锁可以减少数据库锁等待，提升吞吐量。不过代价是遇到冲突时需要业务层处理重试，这对代码设计有一定要求。
在Node.js生态里，Prisma作为类型安全的ORM，并没有提供类似@version的装饰器来自动生成乐观锁SQL，但它的updateMany方法很适合实现这一模式。理解版本号控制之前，先要明确一个原则：任何更新都必须携带版本号条件，并且成功更新后版本号必须递增。如果只读取版本号而不在更新条件中使用，乐观锁就形同虚设。
二、Prisma模型设置与基础更新方法
先在Prisma schema中给需要并发控制的表增加version字段。以订单表为例，除了业务字段，增加一个整数列，并设置默认值为1表示初始版本。后续每次变更都要让version加一。下面是一个简化模型：
model Order {
id Int @id @default(autoincrement())
userId Int
status String @default("PENDING")
amount Int
version Int @default(1)
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
注意version字段不能放在@updatedAt上做自动更新，因为只有在特定业务更新成功时才需要递增版本号，而且递增必须显式控制。Prisma的updateMany允许我们在where条件里同时指定id和version，data里使用increment操作让version增加1。核心代码如下：
const order = await prisma.order.findUnique({
where: { id: orderId },
});
if (!order) throw new Error('订单不存在');
const result = await prisma.order.updateMany({
where: {
id: order.id,
version: order.version, // 只有版本号一致才允许更新
},
data: {
status: 'PAID',
version: { increment: 1 },
},
});
if (result.count === 0) {
throw new Error('订单状态已被其他请求修改，请刷新后重试');
}
这里用updateMany而不是update是有原因的。update在找不到匹配记录时会抛出P2025异常，虽然可以捕获，但更新条件里混入version后，异常可能来自id不存在，也可能来自版本号不匹配，语义不够清晰。updateMany直接返回匹配并更新的行数，count为0就代表版本号已经过期，可以精确识别为并发冲突。
还需要注意版本号递增必须使用increment操作，不能先读取旧值再写回version加一。如果两个请求都读到version等于3，都写回4，即使其中一个更新条件带了version=3也只有一行会成功，但成功后的版本号应该是4，另一个失败后重试读取时会读到4，逻辑仍然正确。使用increment可以确保数据库端原子递增，避免自己计算带来的精度问题。
三、并发冲突检测与重试策略
实际业务中不能一遇到版本冲突就直接返回错误，很多场景下重试一两次就能成功。比如用户快速点击两次支付，第二次请求读到旧版本后第一次已经更新成功，第二次更新会因为version不匹配而失败，此时直接给用户报错体验很差。更合适的做法是捕获冲突后进行有限次重试，每次重试重新读取最新数据，基于最新版本重新执行业务逻辑。
下面是一个通用的带重试的更新函数，适用于钱包扣款、库存扣减等简单更新场景：
async function deductBalanceWithRetry(walletId, amount, maxRetries = 5) {
for (let attempt = 0; attempt < maxRetries; attempt++) {
const wallet = await prisma.wallet.findUnique({
where: { id: walletId },
});
if (!wallet) throw new Error('钱包不存在');
if (wallet.balance < amount) {
throw new Error('余额不足');
}
const result = await prisma.wallet.updateMany({
where: {
id: wallet.id,
version: wallet.version,
},
data: {
balance: wallet.balance - amount,
version: { increment: 1 },
},
});
if (result.count === 1) {
return wallet.balance - amount;
}
// 冲突后简单退避，避免立刻重试撞车
await new Promise(resolve => setTimeout(resolve, 20 * (attempt + 1)));
}
throw new Error('并发请求过多，请稍后重试');
}
在这个循环里，每次重试都会重新读取数据库里的最新版本，因此不会一直拿着旧版本硬试。延迟时间使用线性的20毫秒、40毫秒、60毫秒，实际项目里如果冲突频繁，可以改成指数退避加随机抖动，避免多个请求同时重试再次冲突。最大重试次数也要根据业务容忍度设置，支付、下单等核心操作可以设置5到10次，而普通信息修改设置3次即可。
需要强调，重试只适合幂等或可重复执行的业务操作。如果更新前有外部接口调用、发送消息等副作用，必须把这些副作用放到更新成功之后执行，或者在事务中保证一致性。否则第一次尝试失败但副作用已经发生，重试会导致重复执行。对于非幂等操作，更安全的做法是直接返回版本冲突错误，让客户端刷新后重新提交。
四、事务内的组合更新与常见误区
有些业务需要同时更新多张表，而且每张表都有版本号。单一的乐观锁更新无法保证多表之间的一致性，必须把这些更新放进同一个数据库事务。Prisma的$transaction支持交互式事务，可以在事务内做读取判断、执行多个更新，并通过抛出异常让所有修改回滚。下面是一个订单支付场景，同时校验并更新钱包和订单状态：
async function payOrder(orderId) {
return prisma.$transaction(async (tx) => {
const order = await tx.order.findUnique({
where: { id: orderId },
});
if (!order || order.status !== 'PENDING') {
throw new Error('订单状态不允许支付');
}
const wallet = await tx.wallet.findUnique({
where: { userId: order.userId },
});
if (!wallet) throw new Error('钱包不存在');
if (wallet.balance < order.amount) throw new Error('余额不足');
const walletUpdate = await tx.wallet.updateMany({
where: {
id: wallet.id,
version: wallet.version,
},
data: {
balance: wallet.balance - order.amount,
version: { increment: 1 },
},
});
if (walletUpdate.count === 0) {
throw new Error('钱包数据已变更，请重试');
}
const orderUpdate = await tx.order.updateMany({
where: {
id: order.id,
version: order.version,
},
data: {
status: 'PAID',
version: { increment: 1 },
},
});
if (orderUpdate.count === 0) {
throw new Error('订单状态已变更，请重试');
}
return { orderId, status: 'PAID' };
});
}
事务内使用乐观锁时，版本冲突会抛出异常，Prisma会自动回滚事务内已经执行过的所有更新。上面代码中如果钱包更新成功但订单更新失败，钱包的扣减会被回滚，不会出现只扣钱不改订单状态的中间态。不过要注意事务本身并不能提升并发性能，它只是保证原子性。多个事务同时操作同一钱包时，仍然只能有一个成功，其余会因为版本号条件不匹配而失败，需要配合外层重试。
最后说几个容易踩的坑。第一，不要用updatedAt时间戳替代version字段，部分数据库时间精度不够，同一毫秒甚至同一秒内的两次更新可能得到相同时间戳，导致冲突检测失效。第二，版本号必须是数据库端原子递增，不要读出旧值后在代码里加一写回。第三，如果业务更新前后字段值恰好相同，比如把状态改为它当前已经是的状态，某些数据库可能不会产生实际行变更，但Prisma的updateMany返回count的行为可能因数据库不同而有差异，最好在更新时确保至少version发生变化，避免依赖count判断业务变更。第四，不要把重试做成无限循环，必须设置上限并记录日志，方便排查高并发下的冲突热点。