Promise状态一旦变为fulfilled或rejected即不可逆，保障异步结果可预测、避免重复处理、确保链式调用确定性、简化错误边界，并需警惕resolve/reject参数的可变性陷阱。
Promise的状态一旦从 pending 变为 fulfilled 或 rejected，就再也无法更改。这个不可逆性不是限制，而是设计保障——它让异步流程的执行结果可预测、可追溯，避免了状态混乱引发的业务逻辑错误。
防止重复处理成功或失败分支
由于 Promise 状态不可变，.then() 和 .catch() 中的回调最多只执行一次，即使多次调用 .then() 也只会复用已确定的结果。这天然规避了“同一笔订单被多次支付成功回调处理”“同一个错误被反复上报”等典型问题。
- 例如：用户点击提交按钮后，用 Promise 封装 API 请求，后续所有 .then() 都拿到同一个响应数据，不会因 UI 层多次绑定回调而触发重复提交逻辑
- 若手动模拟可变状态（如用普通对象维护 status 字段），反而容易在竞态条件下误判，比如请求已成功但界面仍显示加载中
确保链式调用的确定性
Promise 链（.then().then().catch()）依赖上一环节返回值决定下一环节走向。状态不可逆保证了每个环节看到的输入是稳定、唯一的——无论中间有多少个 .then() 监听，它们都基于同一个既定结果做转换。
- 比如：登录请求返回 token 后，后续所有 .then() 都能安全地拿该 token 去请求用户信息，不用担心 token 被中途覆盖或清空
- 若状态可变，链中某处意外修改了前序结果，后续环节可能拿到脏数据，导致权限校验失败或页面渲染异常
简化错误边界与重试逻辑
不可逆性让错误处理更清晰：rejected 状态一旦确立，就不会被后续 resolve 覆盖。这使得你可以放心地在 .catch() 中做统一兜底（如跳转错误页、弹提示），而不必担心“错误被悄悄恢复成成功”。
- 重试时应创建新 Promise（如 retry(() => apiCall())），而不是试图“重置”旧 Promise 的状态——后者根本不可行，强行封装反而掩盖问题
- 某些场景下需区分“暂时失败”和“永久失败”，这时应在 reject 时携带明确 reason（如 { code: 'NETWORK_ERROR' }），靠状态不可逆 + 错误分类来驱动不同恢复策略
警惕“伪不可逆”陷阱：resolve/reject 参数不等于状态本身
状态不可逆 ≠ 返回值不可变。Promise 可以 resolve 一个引用类型（如对象），后续代码仍可修改该对象属性。业务逻辑若依赖对象内部字段做判断，就可能产生隐性状态漂移。
- 例如：Promise.resolve({ data: null }).then(res => { res.data = 'ok'; return res; })，虽然 Promise 状态没变，但下游拿到的 data 已被篡改
- 建议对关键响应做浅拷贝或使用不可变结构（如 Object.freeze() 或 Immutable.js），把“不可逆”从状态层延伸到数据层
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
