JavaScript异步方案选择取决于场景：回调适用于单层简单操作，Promise解决嵌套与错误捕获，async/await提升可读性但需注意串行误用；三者语义不同，多次触发场景应选EventTarget等替代方案。
JavaScript 异步代码不是“选哪种更高级”，而是“在什么场景下，哪种写法最不容易出错、最易维护”。回调函数没过时，Promise 不是银弹，async/await 也不是万能糖衣——它们解决的是不同层次的问题。
回调函数：适合简单、一次性、无依赖的异步操作
回调是最原始也最直接的方式，适用于像 setTimeout、fs.readFile（Node.js）这类单次触发、逻辑扁平的场景。但它的问题不在语法，而在控制流：嵌套过深、错误处理分散、无法用 return 或 throw 统一中断。
常见错误现象：
- 回调里再嵌回调，形成“回调地狱”（如连续读两个文件再拼接）
- 忘记检查 err 参数，导致异常静默失败
- 在循环中直接用闭包变量（如 for (var i...)），所有回调共享同一个 i
实操建议：
- 仅用于单层异步，例如 setTimeout(() => console.log('done'), 100)
- 总是先判断 if (err) return callback(err)，避免后续逻辑执行
- 循环中用 let 声明变量，或用 forEach 替代 for 避免闭包陷阱
Promise：解决回调嵌套与错误统一捕获，但不自动执行
Promise 的核心价值不是“看起来更现代”，而是把异步操作变成可组合、可链式处理的值。它不改变异步本质，但让“成功走一条路、失败走另一条路”变得结构清晰。
使用场景：
- 需要串行多个异步操作（如获取 token → 调 API → 处理响应）
- 需要并行发起多个请求并等待全部完成（Promise.all）
- 封装老式回调 API（如用 new Promise 包一层 fs.readFile）
容易踩的坑：
- Promise 构造器里的函数会**立即执行**，不是“定义后才运行”
- .then() 中抛出错误不会被外层 try/catch 捕获，必须用 .catch() 或链末尾补 .catch()
- Promise.all 遇到任意一个 reject 就短路，若需全返回结果，改用 Promise.allSettled
async/await：让异步代码写得像同步，但 await 只对 Promise 生效
async/await 是 Promise 的语法糖，不是新机制。它的优势是线性阅读体验和自然的 try/catch 错误处理；劣势是容易误以为“加了 await 就万事大吉”，而忽略底层仍是事件循环驱动。
立即学习“Java免费学习笔记（深入）”；
参数差异与限制：
- await 只接受 Promise、thenable 或原始值；对普通函数、对象、undefined 等直接返回，**不会等待**
- async 函数总是返回 Promise，即使你 return 42，实际返回的是 Promise.resolve(42)
- 不能在顶层模块作用域（非函数内）直接用 await（ES2022 起支持 top-level await，但仅限模块上下文）
性能影响：
- 没有额外开销，编译后就是 Promise.then 链
- 但滥用 await 会造成本可并行的操作被强制串行（例如连续写 await fetch(a); await fetch(b)），应改用 Promise.all([fetch(a), fetch(b)])
三者混用时最容易被忽略的一点
回调函数可以随时被调用多次，Promise 和 async/await 都基于“单次决议”语义：一个 Promise 只能 resolve 或 reject 一次，后续调用被忽略。如果你封装的是会多次触发的异步源（如事件监听、WebSocket 消息、RxJS 流），强行套用 Promise 会导致丢失中间数据——这时候该用 EventTarget、Observable 或 AsyncIterator，而不是硬塞进 async/await 里。
