promise的“单向转换”是为保障异步结果强一致性而设计的底层契约：状态pending→fulfilled/rejected不可逆，天然规避竞态、确保回调确定性、支撑组合语义与错误透传。
Promise 的“单向转换”特性——即状态只能从 pending → fulfilled 或 pending → rejected，且不可逆——不是语法糖的副产品，而是为保障异步结果强一致性而刻意设计的底层契约。它让开发者能脱离“时机焦虑”，专注逻辑本身。
用状态锁定替代竞态判断
在并发请求、重复提交、快速切换等场景中，多个异步操作可能同时触发，但业务往往只应接受最先完成（或最先失败）的结果。利用 Promise 状态不可变的特性，可天然规避竞态问题。
- 手动创建 Promise 时，resolve/reject 只有第一次调用生效，后续调用被静默忽略
- 无需额外加锁、标记位或时间戳比对，状态机自身已提供原子性保证
- 例如：用户连续点击“提交订单”，每次点击都 new 一个 Promise，但服务端响应后仅首个 resolve 生效，其余响应自动丢弃
构建确定性回调执行路径
因为状态一旦固化，.then() 和 .catch() 的执行就与调用时机解耦：无论在 pending 期还是 fulfilled/rejected 后调用，都能拿到对应结果。这使得逻辑编排更鲁棒。
- 异步操作完成前注册的回调，进入内部队列等待触发
- 异步操作已完成再注册的回调，立即用缓存的 value 或 reason 执行
- 适合封装 SDK 或中间件：如统一鉴权模块返回一个 Promise，业务层随时 .then() 获取 token，不关心它是否已拉取完毕
组合多个 Promise 时保持链式确定性
Promise.all、Promise.race、Promise.any 等静态方法，其行为全部建立在各子 Promise 状态不可逆的前提上。没有这个前提，组合语义将无法定义。
- Promise.all 要求所有 fulfilled 才 resolve —— 若某个 Promise 状态可回滚，结果就不可信
- Promise.race 返回第一个 settled 的结果 —— “第一个”依赖状态固化的时间点，而非回调执行顺序
- 手写重试逻辑时（如 reject 后自动 retry），每次 retry 都应返回新 Promise，避免复用旧实例导致状态混乱
错误传播与降级策略的可靠性基础
Promise 链中一旦进入 rejected 状态，若未被 .catch() 拦截，错误会沿链向下透传；而 fulfilled 状态则持续传递 value。这种稳定流向是实现容错逻辑的基石。
- 可安全设计 fallback：fetch 失败 → 读本地缓存 → 缓存也无 → 显示默认数据，每步都是独立 Promise
- 避免“半成功”陷阱：比如上传图片 + 提交表单，若用两个独立回调，可能出现图片上传成功但表单提交失败的中间态；用 Promise 链可确保整体视为一个原子事务
- 监控埋点可精准绑定到状态节点：.finally() 中统计耗时，.catch() 中上报错误类型，每个钩子语义明确、不重叠
