JavaScript异步编程本质是通过回调函数实现非阻塞执行，其由事件循环调度宏/微任务，但易导致回调地狱；Promise和async/await由此演进而来。
JavaScript 异步编程，本质是让代码在等待某些耗时操作（比如网络请求、定时器、文件读取）完成时，不卡住主线程，而是继续执行后续任务。它靠的是“不等结果先往下走，结果到了再通知你”这个思路，而回调函数就是最基础的“通知你”的方式。
回调函数是怎么被调用的
回调函数不是自己主动运行的，而是被另一个函数“收下”，并在合适时机“反手调用”——也就是“回调”。这种控制权从你手上交出去的过程，叫控制反转（IoC）。
- 你写一个函数，比如
onSuccess，把它当作参数传给fetchData -
fetchData内部执行异步操作（如模拟请求），完成后才执行你传进来的onSuccess - 此时
onSuccess就是回调函数，它的执行时机由fetchData决定，不是你直接调用的
为什么需要回调函数
因为 JavaScript 是单线程的，不能像多线程语言那样“挂起一个任务，去干别的”。回调提供了一种非阻塞的协作机制：
- 用户点击按钮 → 注册一个点击回调，不耽误页面渲染和其他逻辑
- 发起 API 请求 → 传入成功/失败回调，请求发出去就立刻返回，界面保持响应
- 设置
setTimeout→ 把回调放进任务队列，主线程空闲后再执行，不会停掉整个脚本
回调函数和事件循环的关系
回调能不能立刻执行，取决于它属于哪一类任务：
立即学习“Java免费学习笔记（深入）”；
- 宏任务回调：比如
setTimeout、setInterval的回调，进宏任务队列，等当前所有同步代码 + 所有微任务跑完后才执行 - 微任务回调：比如
Promise.then()的回调，进微任务队列，会在当前宏任务结束、下一个宏任务开始前集中执行 - 同步回调：比如数组的
map、forEach传入的函数，是立即执行的，不涉及事件循环
回调函数容易出什么问题
最典型的是嵌套过深，也就是“回调地狱”：
- 多个异步操作顺序依赖时（如：登录 → 获取用户信息 → 获取订单 → 获取订单详情），回调一层套一层
- 代码向右偏移严重，难以阅读、调试和维护
- 错误处理分散，每个回调都要单独写
if (err) ... - 无法用
return、throw或try/catch统一控制流程
这些问题后来催生了 Promise 和 async/await，但理解回调仍是掌握异步逻辑的起点。
