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 链末端）完全无感。
php中级教程之ajax技术
下载
AJAX即“Asynchronous Javascript And XML”（异步JavaScript和XML），是指一种创建交互式网页应用的网页开发技术。它不是新的编程语言，而是一种使用现有标准的新方法，最大的优点是在不重新加载整个页面的情况下，可以与服务器交换数据并更新部分网页内容，不需要任何浏览器插件，但需要用户允许JavaScript在浏览器上执行。《php中级教程之ajax技术》带你快速
立即学习“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
真正难的不是语法选择，而是判断哪部分该并发、哪部分必须串行、哪部分可以丢弃错误而不影响主流程——这些没法靠工具自动推导，得看业务逻辑本身是否容错。
