闭包是构建一致性的关键支撑点，但需配合状态校验、显式控制流和补偿机制；通过固化事务元数据、共享状态对象协调、快照分段回滚及防护引用污染等手段实现数据一致性。
闭包本身不保障数据一致性，但它能稳定携带和隔离上下文，是构建一致性的关键支撑点。真正的一致性要靠状态校验、显式控制流和补偿机制共同实现。
用闭包固化不可变的事务元数据
在任务启动时，把 transactionId、原始参数、deadline、预期版本号等关键信息封入外层作用域，后续所有异步步骤都从同一闭包读取：
- 所有子任务共享同一个 transactionId，用于日志串联、幂等判断和错误归因
- 原始请求参数（如商品 ID、数量）被闭包捕获后不再传参，避免中间环节篡改或遗漏
- 统一设置 deadline = Date.now() + 30000，每个异步步骤可主动检查是否超时并放弃执行
用共享状态对象配合 Promise 链做轻量级协调
不依赖 return 传递值，而是让每个 .then 回调操作同一个闭包内维护的状态对象：
- 定义 const status = { inventory: false, order: false, notify: false }
- 扣库存成功 → status.inventory = true；失败则写入 status.error = 'inventory_failed'
- 最终统一判断：Object.values(status).every(v => v === true) 再决定 commit 或触发 rollback
用闭包快照支持分段回滚
虽无数据库 savepoint，但可在关键步骤前用闭包保存现场，出错时直接恢复：
- 扣库存前，闭包记录 snapshotBeforeInventory = currentStock
- 写订单前，保存草稿 draftOrder = { ... }
- 任一环节失败，调用 restoreInventory(snapshotBeforeInventory) 或 cancelDraft(draftOrder)，这些函数也通过同一闭包访问所需上下文
避开闭包带来的“伪一致性”陷阱
闭包保值不保正确性，以下情况需额外防护：
- 若捕获的是对象引用，外部意外修改会导致后续步骤读到脏数据 → 建议用 structuredClone() 或 Object.freeze()
- 多个并发事务不能复用同一个闭包实例 → 每次调用 createTransaction(...) 必须新建作用域
- 避免在闭包中持有未受控的全局变量或单例状态，否则会跨事务污染
