Prisma 实现扣减后值不小于0才落库的并发安全操作方案咨询

很多人碰到这个需求第一反应是套事务先查存量、判断够不够再扣，实际上这种写法在并发场景下必出超扣问题——两个同时打进来的请求查到的初始存量一样，各自判断完都觉得够扣，最后数据库里的数值直接被扣成负数。下面是经过生产验证的最优实现，完全不用靠复杂的事务逻辑，性能和安全性都拉满。

首选方案：数据库层原子条件更新（无并发超扣风险） #

你在文档里没找到现成实现，本质是Prisma没有把「带条件的批量更新+返回行数判断」组合成库存扣减的专属方案，只是把对应的原子API开放出来了，完全可以用现有能力组合实现，不需要依赖额外的插件。
核心逻辑是把「扣减后不能小于0」的校验直接下推到数据库层，让数据库在执行更新的同时完成校验，单条带条件的UPDATE语句是数据库引擎层面保证原子性的，天然免疫并发竞争。

实际代码示例：

// 以扣减商品库存为例，targetId是要操作的记录ID，deductCount是本次要扣的数值
const updateResult = await prisma.product.updateMany({
  where: {
    id: targetId,
    // 核心校验条件：当前剩余值 >= 待扣减值，从根源上避免扣成负数
    stock: {
      gte: deductCount
    }
  },
  data: {
    stock: {
      decrement: deductCount
    }
  }
})

// 根据实际更新的行数判断执行结果
if (updateResult.count === 0) {
  // 没有命中任何更新条件，说明当前剩余值不够扣，直接抛出对应错误即可
  throw new Error('当前数值不足，扣减失败')
}

这个方案的并发安全性由数据库的行级锁机制保障：不管同时打进来多少个扣减请求，数据库都会自动对操作的行加排他锁，按顺序串行完成「判断存量-扣减数值」的全流程，根本不会出现两个请求同时读到同一个旧值、最后超扣的问题，连显式的事务包裹都不需要，性能比传统的「事务内先查再改」高一个量级。

兜底方案：带锁的交互式事务 #

如果你的扣减逻辑需要额外做关联表查询、扣减流水记录、跨表校验等不能用单条原子更新完成的操作，再考虑用交互式事务。这里一定要避开绝大多数人踩过的坑：

• 错误写法（并发下必出超扣）：

  // 不要这么写！两个并发请求同时读到相同的初始值，校验完全失效
  await prisma.$transaction(async (tx) => {
    const current = await tx.product.findUnique({ where: { id: targetId }})
    const remain = current.stock - deductCount
    if (remain < 0) throw new Error('库存不足')
    await tx.product.update({ where: { id: targetId }, data: { stock: remain }})
  })
  

• 正确写法的核心原则：在事务内读取待扣减的目标记录时，必须强制加行级排他锁，保证读到的值不会被其他并发事务修改；如果Prisma版本不支持原生锁查询，直接回到首选的原子更新方案，不要硬凑事务写法。

常见避坑提醒 #

• 不要以为套了$transaction就自动有并发安全性，事务的隔离级别、读写操作的顺序不对，照样会出现超扣
• 不要用应用层本地锁、接口缓存这类方案控制扣减并发，多实例部署的服务里这类锁根本管不住跨进程的请求
• 不要用无校验的update+decrement直接扣减，没有条件判断的更新操作在并发下必然会出现数值为负的情况

内容的提问来源于stack exchange，提问作者Riven