javascript异步编程是什么_回调函数如何工作【教程】_技术教程

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 注册的函数，本质也是回调），但你不再需要手动管理执行时机和错误分支。

fetch().then(. ..).catch(...) 的 .then 回调，由 Promise 状态变更自动触发，无需你手写 if (success) cb(result)
async/await 让异步代码看起来像同步，但 await 后面仍是 Promise，最终仍落在 resolve/reject 触发的回调上
直接写回调仍有价值：写底层库、兼容老环境、或需要精细控制执行时机（如自定义调度器）

真正容易被忽略的点是：回调函数的 this 指向和闭包变量生命周期。传给 addEventListener 或 setTimeout 的回调，this 默认不是外层对象；循环中为每个元素绑定回调时，若用 var 声明计数器，所有回调共享同一个 i——这些问题和异步无关，却总在回调里爆发。