JavaScript异步编程本质是通过回调函数实现非阻塞执行，其由事件循环调度宏/微任务，但易导致回调地狱；Promise和async/await由此演进而来。

JavaScript 异步编程，本质是让代码在等待某些耗时操作（比如网络请求、定时器、文件读取）完成时，不卡住主线程，而是继续执行后续任务。它靠的是“不等结果先往下走，结果到了再通知你”这个思路，而回调函数就是最基础的“通知你”的方式。

回调函数是怎么被调用的

回调函数不是自己主动运行的，而是被另一个函数“收下”，并在合适时机“反手调用”——也就是“回调”。这种控制权从你手上交出去的过程，叫控制反转（IoC）。

• 你写一个函数，比如 onSuccess，把它当作参数传给 fetchData
• fetchData 内部执行异步操作（如模拟请求），完成后才执行你传进来的 onSuccess
• 此时 onSuccess 就是回调函数，它的执行时机由 fetchData 决定，不是你直接调用的

为什么需要回调函数

因为 JavaScript 是单线程的，不能像多线程语言那样“挂起一个任务，去干别的”。回调提供了一种非阻塞的协作机制：

• 用户点击按钮 → 注册一个点击回调，不耽误页面渲染和其他逻辑
• 发起 API 请求 → 传入成功/失败回调，请求发出去就立刻返回，界面保持响应
• 设置 setTimeout → 把回调放进任务队列，主线程空闲后再执行，不会停掉整个脚本

回调函数和事件循环的关系

回调能不能立刻执行，取决于它属于哪一类任务：

• 宏任务回调：比如 setTimeout、setInterval 的回调，进宏任务队列，等当前所有同步代码 + 所有微任务跑完后才执行
• 微任务回调：比如 Promise.then() 的回调，进微任务队列，会在当前宏任务结束、下一个宏任务开始前集中执行
• 同步回调：比如数组的 map、forEach 传入的函数，是立即执行的，不涉及事件循环

回调函数容易出什么问题

最典型的是嵌套过深，也就是“回调地狱”：

• 多个异步操作顺序依赖时（如：登录 → 获取用户信息 → 获取订单 → 获取订单详情），回调一层套一层
• 代码向右偏移严重，难以阅读、调试和维护
• 错误处理分散，每个回调都要单独写 if (err) ...
• 无法用 return、throw 或 try/catch 统一控制流程

这些问题后来催生了 Promise 和 async/await，但理解回调仍是掌握异步逻辑的起点。