17370845950

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 的参数），用纯回调很容易写出缩进越来越深、错误处理重复、中间状态难传递的代码。这不是写法问题，是控制流表达力的天然瓶颈。

• 每层都要写 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。别在回调里硬扛复杂流程，那不是节俭，是给自己埋雷。