Promise状态不可逆，因其设计为单次触发的锁存器：一旦从pending变为fulfilled或rejected，状态即永久锁定，后续resolve/reject调用被忽略；这是Promise/A+规范强制要求，以确保结果确定性、避免竞态、明确回调语义并保障微任务执行一致性。
因为 Promise 的状态设计就是一次性决断机制——它不是“可切换的开关”，而是“单次触发的锁存器”。一旦从 pending 变为 fulfilled 或 rejected，内部状态字段（如 PromiseState）就被永久写死，后续所有 resolve() 或 reject() 调用都会被直接忽略。
状态不可逆的核心原因
这并非语言限制，而是 Promise/A+ 规范强制要求的行为，目的是保证异步操作结果的确定性与可预测性：
- 避免竞态混乱：如果允许多次状态变更，多个异步回调（比如两个 setTimeout、多个 API 响应、或手动多次调用 resolve）就可能相互覆盖，导致最终结果不可控、调试困难
-
保障 then/catch 的语义清晰：
.then(onFulfilled, onRejected)的行为只取决于第一次确定的状态；若状态可反复变，回调该执行哪一次？规范必须给出唯一答案 -
微任务队列依赖稳定状态：Promise 的
then回调被推入微任务队列时，依据的是当前已锁定的状态。如果状态还能变，微任务执行时就可能拿到过期或矛盾的结果
代码层面怎么实现“不可逆”
手写 Promise 时，关键逻辑就在 resolve 和 reject 方法的开头加状态守卫：
- 只有当
this.status === 'pending'时，才允许更新状态和结果值 - 否则直接 return，不做任何事（不报错、不警告、不重置）
- 这种“守门人”检查，让第二次及以后的调用完全失效
一个典型误区场景
很多人以为下面这段代码会让 Promise “从失败变成功”：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
const p = new Promise((resolve, reject) => {
reject('出错了');
resolve('其实没问题'); // 这行不会生效
});
实际上：reject 执行后状态立刻变为 rejected，再调用 resolve 时发现状态已非 pending，直接跳过——Promise 仍处于 rejected 状态，且永远如此。
这不是缺陷，而是契约
Promise 不是对“过程”的建模，而是对“终局结果”的承诺。就像签合同：一旦签字生效（fulfilled/rejected），就不能因为反悔或新消息而撤回。这种不可逆性，恰恰是它能可靠串联异步流程、支撑链式调用（.then().then().catch()）的底层基石。
