JavaScript异步编程本质是“发起请求后先干别的，有结果再处理”，回调函数需手动调用才执行，否则静默失效；回调地狱源于嵌套依赖与控制流耦合，而Promise/async-await通过标准化执行时机和错误冒泡优化了这一模式。
JavaScript 异步编程不是“等完再干”，而是“发起请求后先干别的，有结果了再处理”；回调函数是它最基础的响应机制，但不是自动触发的魔法——它得被你显式调用，且执行时机完全取决于调用它的那层代码。
回调函数必须被手动执行，否则永远不会运行
很多人以为把函数传进去就等于“注册监听”，其实只是存了个引用。JS 不会自动在某个事件发生后调用它，除非某段代码（比如 setTimeout 内部、fs.readFile 完成后、或你自己的逻辑）明确写了 callback() 或 cb(data)。
- 常见错误：传了函数却忘了在异步操作完成时调用它，导致程序静默卡住，无报错也无输出
- 典型场景：封装一个模拟 API 请求的函数，忘记在
setTimeout回调里执行传入的callback - 示例：
function fakeApi(callback) { setTimeout(() => { // ❌ 忘了这一行：callback('done') }, 100) }
回调地狱（Callback Hell）的本质是嵌套 + 控制流耦合
不是嵌套本身有问题，而是当多个异步操作存在依赖关系（B 要等 A 结果，C 要等 B 结果），又全靠回调传递数据和错误时，缩进越来越深，错误处理重复，逻辑难以复用。
- 错误处理容易遗漏：每个回调里都得写
if (err) return handleError(err)，漏一处就崩 - 参数顺序不统一：Node.js 风格是
(err, data)，前端事件回调常是(event)，混用易出错 - 无法用
return中断流程：在内层回调里return只退出当前函数，不影响外层 - 调试困难：堆栈里看不到完整调用链，只看到
setTimeout→anonymous→anonymous
为什么现在很少直接写回调？不是它错了，而是有更好的抽象
Promise 和 async/await 没有消灭回调，而是把“谁来调用回调”“错误怎么冒泡”“成功值怎么传递”这些重复逻辑标准化了。它们底层依然可能用回调实现（比如 Promise.then 注册的函数，本质也是回调），但你不再需要手动管理执行时机和错误分支。
立即学习“Java免费学习笔记（深入）”；
-
fetch().then(...).catch(...)的.then回调，由 Promise 状态变更自动触发，无需你手写if (success) cb(result) -
async/await让异步代码看起来像同步，但 await 后面仍是 Promise，最终仍落在 resolve/reject 触发的回调上 - 直接写回调仍有价值：写底层库、兼容老环境、或需要精细控制执行时机（如自定义调度器）
真正容易被忽略的点是：回调函数的 this 指向和闭包变量生命周期。传给 addEventListener 或 setTimeout 的回调，this 默认不是外层对象；循环中为每个元素绑定回调时，若用 var 声明计数器，所有回调共享同一个 i——这些问题和异步无关，却总在回调里爆发。
