javascript异步是单线程事件循环机制，回调函数执行时机由调用方（如settimeout、fs.readfile）调度；node.js采用错误优先回调约定(err, data)，嵌套过深易致回调地狱，应依场景选择回调、promise或async/await。
JavaScript 异步不是“多线程”，而是单线程靠事件循环调度回调函数实现非阻塞执行；回调函数本身不异步，它是否延迟执行，完全取决于谁调用它、怎么排队。
回调函数怎么被触发？关键看谁控制执行权
你写的 function(data) { console.log(data) } 只是一个普通函数。它什么时候跑，不由你决定，而由接收它的那个函数（比如 fs.readFile 或 setTimeout）在底层怎么调度：
-
setTimeout把回调推进宏任务队列，等当前同步代码 + 所有微任务（如Promise.then）执行完、调用栈为空时才执行 -
fs.readFile交由 libuv 后台线程读文件，完成后把回调推入 poll 阶段队列，再由事件循环取出 -
array.map(callback)中的callback是同步执行的——没移交控制权，不算异步回调
为什么 err 总是第一个参数？这不是语法，是 Node.js 生态约定
Node.js 所有标准异步 API（如 fs.readFile、http.get）统一采用 “错误优先回调”（error-first callback），形参固定为 (err, data)：
-
err不为null或undefined，说明出错了，必须处理，否则后续data.xxx会报Cannot read property 'xxx' of undefined -
try...catch捕获不到回调里的错误，因为回调执行时早已脱离原始调用栈 -
浏览器原生 API（如
setTimeout、addEventListener）不走这个约定，它们没有内置错误通道，出错只能靠window.onerror或console.error
嵌套三层以上就危险：回调地狱的真实代价
当多个异步操作强依赖（A 结果是 B 的参数，B 结果又是 C 的参数），纯回调极易失控：
- 每层都要写
if (err) return，漏一个就可能引发静默崩溃 - 想复用中间结果？得手动存变量，作用域容易混乱
- 想加个“全部完成后再汇总”的逻辑？得自己计数或改结构，极易出错
- 缩进越来越深，调试时连哪层对应哪个请求都难定位
示例中这种写法已属高危：
fs.readFile('a.json', (err, a) => {<br> if (err) return;<br> fs.readFile('b.json', (err, b) => {<br> if (err) return;<br> fs.readFile('c.json', (err, c) => {<br> if (err) return;<br> console.log(a, b, c);<br> });<br> });<br>});
回调函数不是过时技术，但必须知道它在哪该用、在哪该换
回调仍是底层事实：Promise 和 async/await 底层依然靠它驱动。但它只适合简单、一次性、无强依赖的场景：
- ✅ 适合：
setTimeout、setInterval、fs.readFile（封装层）、DOM 事件监听（addEventListener） - ❌ 不适合：多步骤数据流（登录 → 获取用户 → 获取订单 → 渲染详情）、需集中错误处理、需条件分支或重试逻辑
- ⚠️ 容易忽略的点：回调里修改闭包变量（如
for (var i = 0; i console.log(i), 100)）会输出三个3，要用let或立即执行函数
真正卡住人的，从来不是“会不会写回调”，而是没意识到——控制权一旦交出去，你就失去了对执行时机、错误传播和流程走向的直接掌控。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
