Promise 是异步流程控制的底层契约，其状态不可逆、then 返回新 Promise、catch 仅捕获前序 rejected，违背 Promise/A+ 规范将导致静默失败或卡死。
Promise 不是语法糖，它是 JavaScript 异步流程控制的底层契约。直接说结论：你写错 then 的调用时机、漏掉 catch 或误用 resolve，代码就可能静默失败或状态卡死——这不是 bug，是违背 Promise/A+ 规范的必然结果。
new Promise 时 executor 立即执行，但异步逻辑必须进微任务队列
很多人以为 new Promise 是“创建一个未来才执行的东西”，其实 executor 函数在构造时就同步运行。问题出在：如果你在里面直接 resolve(123)，那这个 Promise 状态立刻变成 fulfilled；但如果你依赖的是网络请求、setTimeout、fs.readFile 这类异步源，就必须确保它们触发的 resolve / reject 被推入微任务队列（如 Promise.resolve().then()），否则 then 回调无法按预期顺序执行。
常见错误现象：
- Promise 构造函数里写了
console.log('start')，紧接着then里console.log('then')，但输出顺序是then在前、start在后——说明你把异步操作写成了同步假象 - 多个
then链中某个环节没返回 Promise，后续then接收到的是上一步的返回值而非新 Promise，导致链断裂
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 永远用
setTimeout(() => resolve(...), 0)或queueMicrotask(() => resolve(...))模拟异步完成，别直接resolve - Node.js 环境下注意
fs.readFile是回调式 API，需包装成 Promise：new Promise((resolve, reject) => fs.readFile(path, (err, data) => err ? reject(err) : resolve(data)))
then 返回新 Promise，不是原地修改
then 方法每次调用都返回一个全新 Promise 实例，这是链式调用能成立的前提。它的返回值决定下一个 then 的输入：如果回调函数返回普通值（如字符串、数字），新 Promise 状态为 fulfilled，值就是该返回值；如果返回另一个 Promise，则等待它 settle 后再向下传递；如果抛错，则新 Promise 状态为 rejected。
容易踩的坑：
- 在
then回调里写return fetch(...)却没接它的.then，导致下游拿到的是Response对象而非 JSON 数据 - 误以为
promise.then(fn1).then(fn2)中的fn2会收到fn1的原始参数，其实只收到fn1的返回值 - 忘记在
then中显式return，函数默认返回undefined，下游then就拿到undefined
示例对比：
const p = Promise.resolve(1)
p.then(x => x + 1) // 返回 Promise<2>
p.then(x => Promise.resolve(x + 1)) // 同样返回 Promise<2>，但多一层 Promise 包装
p.then(x => { console.log(x); }) // 返回 Promise<undefined>
catch 只捕获前序 Promise rejected，不处理 throw
catch 本质是 then(null, onRejected) 的语法糖，它只响应前一个 Promise 的 rejected 状态。它**不会**自动捕获 then 回调内部 throw 出来的错误——除非那个 then 所在的 Promise 已经处于 pending 状态，并且该 throw 发生在微任务执行阶段。
真实场景中高频出错点：
- 在
then回调里解析 JSON：res.json()失败时抛错，但没被任何catch捕获，因为res.json()自身返回的是 Promise，错误发生在它的微任务中 - 写成
promise.then(fn).catch(handleError)，但fn内部有同步异常（如访问undefined.x），这个异常会被 Promise 自动转为 rejected，所以仍能被捕获；但如果fn是async函数，且内部await后又throw，行为一致 - 漏掉末尾
catch，导致未处理的 rejection 触发unhandledrejection事件，在现代浏览器中会报 warning
建议做法：
- 每个 Promise 链末尾加
.catch(console.error)，哪怕只是占位 - 对
fetch做健壮封装：fetch(url).then(r => r.ok ? r.json() : Promise.reject(r))
Promise.race 和 Promise.all 的拒绝策略差异极大
Promise.race 在任意一个输入 Promise settle 时就立即返回结果，不管成功还是失败；而 Promise.all 必须等全部完成，只要有一个 rejected，就立刻 reject 并丢弃其余结果。
典型误用：
- 用
Promise.race([timeout(), apiCall()])实现超时，但没处理 timeout Promise 自身的 reject，导致未捕获异常 - 用
Promise.all([p1, p2, p3])请求多个资源，其中一个失败整个失败，但业务上希望“尽力而为”，这时该用Promise.allSettled - 在 Node.js 中混用
Promise.all和流式读取（如stream.pipeline），因流错误不走 Promise 流程，导致 race/all 完全失效
性能提示：
-
Promise.race不会取消其他 Promise，只是忽略它们的后续结果；真要取消，请用AbortController配合fetch或自定义可取消逻辑 -
Promise.all的数组长度过大（比如上千项）可能引发内存压力，应考虑分批或使用for...of+await控制并发数
最常被忽略的一点：Promise 状态不可逆是硬性规范，不是约定。你不能靠「多次调用 resolve」来重试，也不能在 pending 时手动修改内部状态字段——所有这些操作都被引擎静默忽略。真正可控的，只有你如何组织 executor 里的异步流程、如何设计 then 链的返回值、以及是否让每个环节的错误都有明确出口。
