JavaScript异步编程本质是避免阻塞主线程，通过将耗时操作交由底层环境处理，主线程继续执行，结果就绪后通知回调；回调函数是基础方式，但易致嵌套过深、错误处理分散，适用于简单场景。
JavaScript 异步编程的本质是避免阻塞主线程
JavaScript 是单线程语言，所有任务都在一个调用栈里顺序执行。如果某个操作（比如读文件、发网络请求）耗时很长，又同步等待结果，整个页面就会卡死。异步编程不是“让 JS 变成多线程”，而是把耗时操作交给浏览器或 Node.js 的底层环境去处理，JS 主线程继续往下走，等结果就绪后再通过某种机制通知你——这就是异步的核心逻辑。
回调函数是最基础的异步处理方式，但容易陷入“回调地狱”
回调函数就是把一个函数作为参数传给另一个函数，后者在异步操作完成时调用它。这是最原始、也最容易出问题的方式。
常见错误现象：
- 嵌套过深：
getData→parseData→saveToDB→notifyUser，四层缩进后难以阅读和调试 - 错误处理分散：每个回调里都要写
if (err)，漏掉一处就可能静默失败 - 无法用
return或throw控制流程：回调里的return只退出当前函数，不影响外层
使用场景：适合简单、一次性的异步操作，比如 setTimeout、setInterval、或封装好的底层 API（如 fs.readFile 的 callback 版本）。
立即学习“Java免费学习笔记（深入）”；
实操建议：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 始终检查回调的第一个参数是否为错误（Node.js 风格约定：
callback(err, result)） - 不要在回调里直接操作 DOM 多次，先攒好数据再批量更新，减少重排重绘
- 避免在循环中直接创建闭包回调（如
for (let i = 0; i console.log(i), 100)），用let声明变量或改用forEach
fs.readFile('./config.json', 'utf8', (err, data) => {
if (err) {
console.error('读取失败:', err.message);
return;
}
try {
const config = JSON.parse(data);
console.log('配置加载成功:', config.host);
} catch (parseErr) {
console.error('JSON 解析失败:', parseErr.message);
}
});
回调函数的参数顺序和错误传递必须严格遵循约定
不同环境对回调参数的约定不同，混用会导致逻辑错乱。Node.js 标准是 callback(err, data)，而浏览器原生 API（如 addEventListener）往往只传事件对象，没有显式错误参数。
关键差异：
-
fs.readFile和http.get（Node.js）：错误优先（error-first），err为null或undefined表示成功 -
setTimeout、requestAnimationFrame：无错误参数，仅执行回调 -
XMLHttpRequest的onload：需手动检查xhr.status；onerror才表示网络失败
性能影响：回调本身开销极小，但频繁创建匿名函数（尤其在循环或高频事件中）会增加 GC 压力。可复用具名函数减少对象分配。
现代开发中应限制回调的使用范围，优先选 Promise / async-await
回调不是“过时”，而是适用边界很窄：当你维护老项目、对接不支持 Promise 的 SDK、或写底层工具函数时才需要它。新代码中强行用回调处理多步骤异步链，几乎必然导致可维护性崩塌。
容易被忽略的一点：即使你不用回调，也要理解它的执行时机——它总是在当前调用栈清空后、下一轮事件循环中执行（即 microtask 或 macrotask 队列）。这意味着 console.log(1); setTimeout(() => console.log(2)); console.log(3) 输出的是 1 3 2，而不是按书写顺序。
