Promise 的三种状态是 pending、fulfilled 和 rejected，其中 fulfilled 与 rejected 合称 settled；状态一旦进入 settled 就不可逆，这是为防止竞态、保障链式调用可预测及简化错误处理而设计的核心机制。
Promise 的三种状态是 pending（待定）、fulfilled（已兑现） 和 rejected（已拒绝）。其中 fulfilled 与 rejected 合称“settled（已确定）”——一旦进入任一 settled 状态，就再也不会变回 pending，也不能在 fulfilled 和 rejected 之间互相切换。
怎么判断当前 Promise 处于哪种状态
JavaScript 原生 Promise 实例**不暴露 status 属性**，无法直接读取 `.status`。所以不能像 `promise.status === 'fulfilled'` 这样检查。但你可以通过以下方式间接识别：
-
观察 then/catch 的执行路径：调用
.then(onFulfilled, onRejected)时，只有对应状态的回调会被触发；如果只传了.then(onFulfilled)，失败时会跳过，进入后续.catch()。 -
用包装类或调试工具辅助：自己实现简易 Promise 类时，可添加
status字段并公开读取方法；开发中也可借助浏览器 DevTools 的断点和 console.log 输出状态流转过程。 -
利用已 settled 的 Promise 行为特征：对一个已 resolve 的 Promise 多次调用
.then()，每次都会立即以相同值执行；同样，已 reject 的 Promise 多次绑定.catch()，也总拿到同一个 error —— 这种“结果复用”就是 settled 的外在表现。
为什么 settled 后不可更改：设计本质决定的保障机制
状态不可逆不是技术限制，而是核心设计原则。它解决的是异步编程中最容易出错的竞态问题：
-
防止多次触发逻辑分支：比如支付请求成功后，不应因 UI 层重复绑定
.then()而导致订单被创建两次；reject 后也不该被后续某处误调的resolve()“覆盖”错误，造成静默失败。 -
保证链式调用可预测：在
fetch().then(parse).then(render).catch(handleError)链中，每个环节都依赖前序输出。如果中间 Promise 状态还能变，后面环节可能拿到不一致的数据，比如 token 突然变成 undefined。 -
简化错误边界处理：一旦进入 rejected，
.catch()就能稳稳接管；你不需要担心“刚报错，下一秒又好了”，也不必写防御性代码去反复校验状态是否被篡改。
常见误解：“不可更改”不等于“返回值不可变”
注意：状态锁定 ≠ 数据冻结。Promise 可以 resolve 一个对象，而这个对象的属性仍可被修改：
const p = Promise.resolve({ count: 0 });
p.then(data => { data.count++; return data; }).then(console.log); // { count: 1 }
// 状态没变，但 data 内容变了
业务中若用对象字段做流程判断（如 if (res.data) {...}），就要意识到这种“内部漂移”风险——状态不可逆管不住引用数据的变更，需靠代码规范或深拷贝规避。
实际开发中该怎么做
- 所有异步操作封装成新 Promise，不要试图“重置”旧 Promise；重试请用
retry(() => api())这类函数重新生成实例。 - 避免在 Promise 执行器中写多个 resolve/reject 调用，只保留一条确定路径；多余调用会被忽略，但易引发理解偏差。
- 调试时关注控制台输出顺序：pending → fulfilled 或 pending → rejected 是唯一合法路径；出现其他组合（如 fulfilled → rejected），说明代码逻辑有误，或用了非标准 Promise 实现。
