JavaScript异步核心是理解Promise状态不可逆及async/await仅为语法糖；需确保executor一次性执行、合理使用Promise.all/race、避免滥用await导致性能下降。
JavaScript 实现异步编程的核心不是“选哪种写法”，而是理解 Promise 是底层契约，async/await 只是它的语法糖——不掌握 Promise 状态流转，await 写出来照样出错。
Promise 状态不可逆，resolve/reject 后再调用无效
很多初学者以为 Promise 像函数一样能多次触发回调，其实一旦进入 fulfilled 或 rejected 状态，后续的 resolve 或 reject 调用会被静默忽略。
常见错误现象：fetch 请求发了两次，但只有第一次响应进了 .then；或在定时器里反复 resolve，结果只生效一次。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把
new Promise的执行器（executor）当作一次性初始化逻辑，所有异步分支必须收束到单次resolve或reject - 需要“重试”或“取消”语义时，不要靠重复调用
resolve，而应封装成新Promise实例（如retry(fetch(...))） - 调试时可加
console.log在resolve前，确认它只执行一次
async/await 不等于同步，await 后面必须是 Promise
await 会自动把非 Promise 值包装成已解决的 Promise，但这不改变执行流本质：它只是暂停当前 async 函数，让出主线程，而非阻塞线程。
使用场景：
- 想顺序等待多个请求，且中间要处理返回值（比如用第一个接口结果拼第二个接口的 URL）
- 需要在
try/catch中统一捕获异步错误（比.catch()更贴近同步习惯）
容易踩的坑：
- 对普通函数或字面量
await getUserName()，如果getUserName没返回Promise，await会立即解包，毫无异步效果 -
await在循环中串行执行（如for循环内await api.call(i)），性能远低于Promise.all并发 -
await不会捕获setTimeout内抛出的错误，除非setTimeout被包进Promise
Promise.all 和 Promise.race 的失败策略完全不同
Promise.all 遇到任意一个 rejected 就立刻 reject，而 Promise.race 是谁先 settle（无论 fulfilled 还是 rejected）谁胜出——这点常被误读为“谁快谁赢”，但“快”包含失败。
性能 / 兼容性影响：
-
Promise.all适合“全都要成功”的场景（如加载多个配置文件），失败后需手动聚合错误或改用Promise.allSettled（注意 IE 不支持） -
Promise.race常用于超时控制：Promise.race([api(), timeout(5000)])，但如果api()先 reject，整个 race 就 reject，可能掩盖超时逻辑 - Node.js 15+ 支持
AbortSignal.timeout()，可替代手写 race 超时，更语义化
真正难的不是写 async 函数，而是判断什么时候不该用 await——比如并行请求、事件监听、流式数据消费，强行串行化反而破坏异步本意。状态管理、错误传播路径、时序依赖，这些才是实际项目里卡住人的地方。
