promise 是对异步操作的标准化封装，核心判断标准是结果是否在未来某个时刻获得且有明确成功/失败状态；纯同步计算或立即完成逻辑不应使用 promise。
Promise 不是异步操作的“解决方案”，而是对异步操作的标准化封装；用错 Promise 比不用更危险——比如在 then 里漏掉 return、滥用 Promise.all 导致错误静默、或把同步逻辑强行包进 new Promise。
什么时候该用 Promise，什么时候不该用？
核心判断标准：是否涉及「未来某个时刻才可获得的结果」且该结果有明确成功/失败两种状态。
- 该用：
fetch、setTimeout封装、Node.js 的fs.promises.readFile、第三方 SDK 返回的Promise对象 - 不该用：纯同步计算（如
JSON.parse）、已知立即完成的逻辑（如return Promise.resolve(data)只为“统一接口”）——这只会增加微任务开销和堆栈深度 - 警惕伪异步：用
new Promise(resolve => { resolve(syncValue); })包裹同步值，会导致调用者必须用await或then，但实际并无异步收益，还掩盖了执行时机
async/await 中的错误捕获为什么总失效？
因为 await 只拒绝（reject）时抛出异常，而「未被 catch 的 Promise rejection」会变成 unhandled rejection，但不会中断后续代码——看起来像“错误消失了”。
- 必须配对使用：
try/catch包住await表达式，或在async函数末尾加.catch() - 避免在循环中直接
await多个请求——单点失败会阻塞全部后续执行；改用Promise.allSettled或手动try/catch每个 -
Promise.all遇到任意一个 rejection 就立刻 reject，不等其余完成；若需全部结果（含失败），必须用Promise.allSettled
async function fetchAll() {
try {
const [a, b] = await Promise.all([
fetch('/api/a'),
fetch('/api/b') // 这里失败 → 整个 Promise.all 立即 reject，a 的响应丢失
]);
return { a, b };
} catch (err) {
console.error('任一请求失败', err);
}
}
Promise 链中哪些操作会“吞掉”错误？
最常见的是在 then 回调里漏写 return，或返回非 Promise 值，导致后续 catch 无法捕获前面的异常。
立即学习“Java免费学习笔记（深入）”；
-
then(onFulfilled)中若onFulfilled抛错，且没有第二个参数onRejected，错误会沿链向后传递；但若链被中断（比如没写catch），就成 unhandled rejection - 在
then里做副作用（如console.log、push数组）却不return，下一个then收到的是undefined，而非上一步的值 - 不要在
then里用throw模拟错误来“跳转”到catch——这是反模式；应统一用Promise.reject()或让底层 Promise 自然 reject
Promise.resolve(42)
.then(x => {
console.log(x); // 42，但没 return → 下个 then 得到 undefined
})
.then(y => console.log(y)) // undefined，不是 42
真正难的不是写 Promise，是判断哪个环节该拒绝、哪个该忽略、哪个该重试、哪个该降级——这些逻辑几乎从不写在 Promise 构造函数里，而藏在业务条件分支中。
