JavaScript异步编程方案如何选择【教程】

javaScript异步编程无最优解，关键在根据错误处理、可读性及业务逻辑选择promise链或async/await；回调函数在未Promise化API中仍必要；try/catch无法捕获未处理的Promise rejection，需全局监听；Generator已淘汰，但其思想被async/await继承。

javascript异步编程没有“最优解”，只有“更合适”——选错方案不会报错，但会在调试时让你反复怀疑人生。

Promise 链 vs async/await：什么时候该切过去

async/await 不是 Promise 的替代品，而是语法糖。真正决定是否切换的关键，是错误处理路径和可读性成本。

• 多个 fetch 串行依赖（比如先登录再拿 Token 再请求数据），用 async/await 能避免嵌套 .then() 和重复的 catch 块
• 并行请求（如同时拉取用户信息和订单列表）仍推荐 Promise.all([p1, p2])，写成 await Promise.all([p1, p2]) 更清晰，但别写成 await p1; await p2;
• 注意 await 会阻塞后续语句执行，若某一步本可不等待（比如发个日志上报），就别 await 它，否则拖慢整体响应

回调函数还没死透：哪些场景绕不开它

不是所有异步操作都封装成了 Promise。node.js 早期 API、部分浏览器事件（如 setTimeout、setInterval）、原生 Web API（如 indexedDB）仍以回调为主。

• setTimeout 和 setInterval 没有原生 Promise 版本，自己封装一层 timeout(ms) 返回 Promise 很常见，但别在每次调用时都新建 Promise —— 可复用
• indexedDB 的 request.onsuccess 仍是回调驱动，强行 Promise 化容易漏掉 onError 或事务中断逻辑
• 第三方库（如旧版 socket.io）若只暴露回调接口，硬套 async/await 反而增加出错概率，不如老老实实用回调 + Promise.resolve() 衔接

try/catch 捕获不了所有错误：async 函数里的坑

try/catch 只能捕获同步抛出的错误和 await 后被 reject 的 Promise，对微任务队列里未处理的 rejection（比如忘记 catch 的 Promise 链末端）完全无感。

立即学习“Java免费学习笔记（深入）”；

• Node.js 中未处理的 Promise rejection 会触发 unhandledRejection 事件，建议全局监听并打日志：process.on('unhandledRejection', (reason) => console.error(reason))
• 浏览器中同理，监听 window.addEventListener('unhandledrejection')，但注意它不捕获已 catch 过又没 re-throw 的错误
• 在 async 函数里调用非 Promise 函数（如直接 json.parse('{') ），错误仍同步抛出，try/catch 有效；但若该函数内部返回一个立刻 reject 的 Promise，就必须 await 后才能进 catch

Generator + co 已淘汰，但 yield* 的思维还在

es6 的 function* 和 co 库曾是过渡方案，现在基本没人用了。但它的核心思想——把异步流程拆成可暂停、可恢复的步骤——被 async/await 继承了下来。

• yield* 在现代代码中仍有价值，比如组合多个异步迭代器（AsyncIterator），但需注意目标环境是否支持（chrome 63+/node.js 10+）
• 某些状态机类逻辑（如 websocket 心跳重连、分段上传）用 async + while + await 比硬套 Promise.allSettled 更可控
• 别为了“看起来高级”而用 yield 替代 await，V8 对 async/await 的优化远超 Generator

真正难的不是语法选择，而是判断哪部分该并发、哪部分必须串行、哪部分可以丢弃错误而不影响主流程——这些没法靠工具自动推导，得看业务逻辑本身是否容错。