闭包不提供事务一致性，但能可靠封装和传递跨异步步骤的上下文数据，是构建一致性的基础；需结合状态校验、显式控制流与闭包固化元数据（如transactionId、deadline）共同实现。
闭包本身不提供事务一致性保障，但它能可靠地封装和传递跨异步步骤所需的上下文数据——这是构建事务一致性的基础支撑。真正的“一致性”需由业务逻辑、状态校验与显式控制流（如重试、回滚标记、幂等键）共同实现，而闭包负责让这些机制始终持有正确的上下文。
用闭包固化关键事务元数据
在事务起始点，把必须贯穿全程的标识和约束条件（如 transactionId、userId、原始请求参数、预期版本号、超时时间）封入外层函数作用域，后续所有异步步骤通过闭包访问，避免因参数遗漏或错传导致状态错位：
- 每个异步操作（如扣库存、写订单、发消息）都从同一闭包中读取 transactionId，用于日志追踪与幂等判断
- 原始输入数据（如商品 ID、数量）被闭包捕获后不可变，防止中间步骤篡改引发校验失败
- 设置统一 deadline = Date.now() + 30000，所有子步骤可据此主动放弃过期任务，避免陈旧状态污染
配合 Promise 链+状态标记做轻量级“软事务”
在 Promise 链中，不依赖 return 传递中间值，而是让每个 .then 回调共享闭包内的 mutable 状态对象，用布尔字段标记各环节完成情况，最后统一校验：
- 定义 const status = { inventory: false, order: false, notify: false }，由闭包持有
- 每个异步步骤成功后设 status.inventory = true；失败则设 status.error = 'inventory_failed'
- 最终 .then(() => { if (Object.values(status).every(v => v === true)) commit(); else rollback(status); })
结合 savepoint 思路模拟分段回滚能力
虽然 JS 没有数据库 savepoint，但可用闭包记录各阶段前的状态快照，在出错时触发对应补偿动作：
- 执行扣库存前，闭包保存当前库存值 snapshotBeforeInventory = currentStock
- 写订单前，保存订单草稿 draftOrder = { ... }
- 任一环节失败，闭包内直接调用 restoreInventory(snapshotBeforeInventory) 或 cancelDraft(draftOrder)
- 这些恢复函数也通过同一闭包访问所需上下文，无需额外传参
避免闭包导致的“伪一致性”陷阱
闭包能保值，但不能保正确性。以下情况会破坏一致性，需额外防护：
- 闭包捕获的是引用类型（如一个对象），若该对象被外部意外修改，后续步骤读到的就是脏数据 → 应使用结构化克隆或冻结（Object.freeze）
- 多个并发调用共享同一个闭包实例 → 必须确保每次事务启动都新建闭包（如 createTransactionFlow(input) 返回新函数）
- 异步操作超时后仍继续执行并写入 → 在闭包中维护 isExpired 标志，每个回调开头检查 if (isExpired) return
