JavaScript异步本质是单线程靠事件循环实现非阻塞执行，回调函数是基础调度机制；其是否异步取决于调用方如何调度，如setTimeout推入宏任务队列，fs.readFile由libuv后台处理后推入poll队列，而array.map的callback同步执行。
JavaScript 异步本质是单线程靠事件循环实现非阻塞执行，不是多线程；回调函数是它最基础的调度机制——你把“做完后干啥”打包成函数交出去，由运行时在合适时机主动调用。
回调函数怎么被触发？关键看谁控制执行权
回调函数本身只是普通函数，能否“异步执行”，取决于它被传给了谁、以及那个函数内部怎么调度它。比如 setTimeout 和 fs.readFile 都会把回调交给底层环境（浏览器或 Node.js）去排队，主线程立刻继续跑，不等。
-
setTimeout把回调塞进宏任务队列，等当前同步代码 + 所有微任务（如Promise.then）执行完、调用栈为空时，才取出执行 -
fs.readFile（Node.js）由 libuv 在后台线程读文件，完成后把回调推入 poll 阶段的队列，再由事件循环调度 - 而
array.map(callback)中的callback是同步执行的——它根本没移交控制权，不算“异步回调”
为什么 err 总是第一个参数？这是约定，不是语法强制
Node.js 风格的异步 API（如 fs.readFile、http.get）统一采用“错误优先回调”（error-first callback），即回调形参固定为 (err, data)。这不是 JavaScript 语言要求，而是生态共识，目的是让错误处理可预测、可批量兜底。
- 如果
err不为null或undefined，说明出错了，必须处理，否则后续逻辑可能崩在data.xxx上 -
try...catch捕获不到回调里的错误，因为回调执行时早已脱离原始调用栈 - 浏览器原生 API（如
setTimeout、addEventListener）不走这个约定，它们没有内置错误通道，出错只能靠console.error或全局window.onerror
const fs = require('fs');
fs.readFile('./config.json', 'utf8', (err, data) => {
if (err) {
console.error('读取失败:', err.message); // 必须判 err，不能跳过
return; // 这个 return 很关键，防止继续执行依赖 data 的代码
}
console.log('配置内容:', data);
});
嵌套三层以上就危险：回调地狱的真实代价
当多个异步操作存在强依赖（比如 A 结果是 B 的参数，B 结果又是 C 的参数），用纯回调很容易写出缩进越来越深、错误处理重复、中间状态难传递的代码。这不是写法问题，是控制流表达力的天然瓶颈。
立即学习“Java免费学习笔记（深入）”；
- 每层都要写
if (err) return，漏一个就可能引发Cannot read property 'xxx' of undefined - 想复用某一步结果？要么闭包捕获，要么提成全局变量，状态污染风险陡增
- 调试时断点打在哪？堆栈里全是
anonymous，看不出哪个回调对应哪次请求 - 想加个超时逻辑？得手动
clearTimeout+ 状态标记，极易遗漏
// 典型回调地狱（不推荐）
requestData('/api/user', (err, user) => {
if (err) return;
requestData(`/api/orders?uid=${user.id}`, (err, orders) => {
if (err) return;
requestData(`/api/detail?id=${orders[0].id}`, (err, detail) => {
if (err) return;
console.log(detail);
});
});
});
回调函数至今仍不可替代——DOM 事件、定时器、老库兼容都靠它；但只要涉及两层以上依赖或需集中错误处理，就该果断切到 Promise 或 async/await。别在回调里硬扛复杂流程，那不是节俭，是给自己埋雷。
