回调函数是异步操作完成后的通知机制，本质是作为参数传递的普通函数，不改变JS单线程同步执行特性；它易导致回调地狱，现代开发应优先使用Promise/async-await封装，但事件监听等多次触发场景仍适合回调。
异步 JavaScript 不是“等一个函数执行完再往下走”，而是“发起一个可能耗时的操作，然后继续干别的，等它好了再通知你”。回调函数就是那个“通知你的方式”——但它本身不解决异步问题，只是最原始的处理机制。
回调函数本质是参数，不是特殊语法
你传给 setTimeout、fs.readFile 或 addEventListener 的那个函数，就是回调函数。它只是被当作值传递进去，由别人在将来某个时刻调用。
- 它没有特殊关键字，不是语言特性，只是函数作为一等公民的表现
- 它不自动“等待”，也不会改变代码执行顺序——JS 仍是单线程同步执行，只是把“后续逻辑”推迟到事件循环的下一轮
- 常见错误：在回调里写
return想返回给外层函数——没用，外层早已执行完毕并返回了
回调地狱（Callback Hell）是怎么来的
当多个异步操作存在依赖关系（比如“读文件 → 解析 JSON → 请求 API → 存数据库”），嵌套回调就不可避免：
fs.readFile('config.json', 'utf8', (err, data) => {
if (err) throw err;
const config = JSON.parse(data);
fetch(`/api/users?id=${config.userId}`, { method: 'GET' })
.then(res => res.json())
.then(user => {
db.save(user, (err) => {
if (err) console.error('save failed');
});
});
});
这种写法的问题不只是缩进深：
立即学习“Java免费学习笔记（深入）”；
- 错误处理分散：每个层级都要单独判断
err或catch - 控制流难追踪：无法用
break、return或try/catch跨层级中断 - 无法原生支持
await或Promise.all等组合能力
现代替代方案不是“不用回调”，而是“不手动写回调”
底层 API（如 Node.js 的 fs.readFile、浏览器的 XMLHttpRequest）仍以回调形式存在，但你应该封装或直接使用 Promise 化版本：
- Node.js 14+ 可直接用
fs.promises.readFile，返回 Promise，支持await - 浏览器中
fetch()原生返回 Promise，无需回调 - 已有回调 API？用
util.promisify（Node）或手写一层包装函数转成 Promise - 绝对避免：在
async函数里又写一层回调——混合范式会让错误堆栈断裂、调试困难
回调仍有不可替代的场景
不是所有异步都适合 Promise。以下情况回调更自然：
- 事件监听：比如
button.addEventListener('click', handler)—— 事件可能触发多次，Promise 只能 resolve 一次 - 流式数据处理：如
readable.on('data', chunk => {...})，每次收到一块数据就处理，不能也不该攒成一个 Promise - 某些底层库（如 WebSocket 的
ws.on('message', ...)）设计上就是事件驱动，强行 Promise 化反而增加复杂度
关键区别在于：回调适合“多次触发 + 主动响应”，Promise 适合“一次结果 + 被动等待”。混淆这两者，是很多异步 bug 的根源。
