异步JavaScript通过回调函数等机制让耗时操作不阻塞主线程；回调是作为参数传入并在特定时机调用的函数，常见错误是误写为callback()而非callback；Node.js习惯(err, data)形式，浏览器事件则无err参数；嵌套回调导致“回调地狱”，现代方案Promise/async-await将其转为链式或同步写法但底层仍依赖回调；事件监听、底层API等场景仍需手动写回调，需注意闭包问题。
异步 JavaScript 不是“等代码跑完再执行下一行”，而是让耗时操作（比如网络请求、文件读取）不卡住主线程，同时通过回调函数或其他机制在操作完成时通知你结果。
回调函数到底长什么样？
回调函数就是一个被当作参数传给另一个函数的函数，在某个时机（比如异步操作结束）被调用。它不是特殊语法，只是函数的使用方式。
常见错误是把回调写成 myFunc(callback()) —— 这会立刻执行 callback 并传入返回值；正确写法是 myFunc(callback)，只传函数引用。
- 回调通常放在异步函数的最后一个参数位置，例如
setTimeout(fn, delay)、fs.readFile(path, callback) - Node.js 的回调习惯是第一个参数为
err，第二个才是结果：(err, data) => { ... } -
浏览器原生 API（如
addEventListener）的回调一般没有err参数，出错靠try/catch或事件对象判断
为什么回调容易变成“回调地狱”？
当多个异步操作需要串行执行（比如“先登录 → 再拉用户信息 → 再加载权限列表”），用纯回调就会层层嵌套：
立即学习“Java免费学习笔记（深入）”；
login(user, (err, token) => {
if (err) throw err;
getUser(token, (err, user) => {
if (err) throw err;
getPermissions(user.id, (err, perms) => {
// …
});
});
});
问题不止是缩进难看：错误处理重复、逻辑拆分困难、无法用 return 或 break 控制流程、调试时堆栈不直观。
- 这不是回调本身的问题，而是嵌套式控制流难以维护
- 现代方案（Promise / async/await）本质是把“嵌套”转成“链式”或“同步写法”，但底层仍依赖回调（比如 Promise 的
.then()就是注册回调） - 即便用 Promise，如果忘记
catch或漏写await，错误依然静默丢失
什么时候还必须手动写回调？
不是所有异步场景都被 Promise 包装过。以下情况你绕不开原始回调：
- 浏览器事件监听：
button.addEventListener('click', handleClick) - Node.js 的某些底层 API（如
stream的'data'事件） - 第三方库明确要求传回调（比如旧版
mongoose的查询方法） - 需要精确控制执行时机的场景（如
requestIdleCallback）
此时要注意：回调中用到的外部变量（比如循环里的 i）容易因闭包捕获到最终值，应改用 let 声明，或用立即执行函数包裹。
真正难的不是写回调，而是判断该不该用、在哪一层抽象掉它。很多“回调地狱”其实是设计问题：过早拆分异步步骤、没封装错误传播路径、或混淆了“并发”和“串行”的需求。
