JavaScript无内置事务机制，需手动设计原子性单元：用数据库事务保障强一致性操作（如订单+库存），跨服务用Saga或补偿机制，避免事务中执行耗时操作，并通过async/await+try/catch控制流程与回滚。
JavaScript 本身没有内置的数据库事务机制，async/await 也不是事务的实现者，而是用来清晰表达异步流程控制的语法糖。要实现“复杂业务逻辑的事务性提交”，关键在于：把多个异步操作（如数据库写入、外部服务调用、文件操作等）组织成一个原子性单元——要么全部成功，要么全部回滚。这需要你手动设计事务边界、错误捕获和补偿逻辑。
明确事务边界与资源协调
事务不是语言特性，而是业务语义。你需要先定义哪些操作必须“一起成功或一起失败”。例如：创建订单 → 扣减库存 → 发送通知。其中前两步通常需强一致性（数据库事务），第三步可最终一致（失败后重试或告警）。
- 把强依赖的操作放在同一个数据库事务中（如使用 Knex、Prisma、TypeORM 的 transaction API）
- 跨服务或跨系统操作无法靠 DB 事务保证，需引入 Saga 模式或本地消息表 + 补偿任务
- 避免在事务中做耗时操作（如 HTTP 请求、文件读写），防止锁持有过久
用 async/await 配合 try/catch 实现执行流控制
async/await 让你用同步风格写异步代码，便于集中处理错误和触发回滚。核心结构是：启动事务 → 依次 await 关键步骤 → 出错则 rollback → 成功则 commit。
示例（以 Prisma 为例）：
立即学习“Java免费学习笔记（深入）”；
const createOrderWithInventory = async (orderData) => {
return await prisma.$transaction(async (tx) => {
// 步骤1：创建订单
const order = await tx.order.create({ data: orderData });
// 步骤2：扣减库存（带乐观锁或版本检查）
const product = await tx.product.findUnique({ where: { id: orderData.productId } });
if (product.stock < orderData.quantity) {
throw new Error('库存不足');
}
await tx.product.update({
where: { id: product.id },
data: { stock: { decrement: orderData.quantity } }
});
// 步骤3：记录操作日志（也在同一事务中）
await tx.auditLog.create({
data: { action: 'ORDER_CREATED', orderId: order.id }
});
return order;
});
};
注意：所有操作都发生在 tx 上下文中，任意一步 reject，整个事务自动回滚。
处理外部依赖的最终一致性
当业务涉及第三方服务（如支付回调、短信发送、ES 索引更新），它们无法纳入数据库事务。此时应分离“核心事务”和“外围动作”：
- 核心步骤（订单+库存）在 DB 事务内完成并持久化
- 外围动作通过事件驱动方式触发（如发 Kafka 消息、写入消息表），由独立消费者重试执行
- 若外围动作失败，不阻塞主流程，但需有监控和人工介入通道
补充：手动回滚与幂等设计
如果所用 ORM 不支持事务嵌套，或操作分散在不同数据源，就得自己管理状态和补偿逻辑：
- 在开始前记录“待办事务快照”（如 Redis 或专用事务表）
- 每步成功后更新状态；失败时按反向顺序调用补偿函数（如“恢复库存”）
- 所有写接口必须支持幂等（用唯一业务 ID 去重），防止补偿重复执行
