JavaScript异步编程关键在理解回调的调用时机、执行主体和上下文；回调是被宿主环境主动调用的参数函数，需避免立即执行错误；回调地狱本质是控制流失控，应拆解为具名函数或升级为Promise/async-await；封装回调API为Promise是必备技能，须注意error-first约定和this绑定。
JavaScript 的异步编程不是靠“学一个概念”就能用好的，关键在理解回调函数到底在哪儿被谁调用、何时执行、上下文是否丢失——它不是语法糖，而是运行时控制流的显式移交。
回调函数就是“你先干别的，等我好了再通知你”的函数
它本质是一个被当作参数传入另一个函数的函数，在特定时机（比如数据加载完成、定时器到期）由宿主环境或库主动调用。不是你手动 callback()，而是别人替你调。
- 常见错误：把回调写成
doSomething(callback())（加了括号），结果变成立即执行并传入返回值，而不是传入函数本身 - 正确写法是
doSomething(callback)或doSomething(() => { /* 逻辑 */ }) - Node.js 的
fs.readFile、浏览器的setTimeout、addEventListener都依赖回调驱动异步流程 - 回调里
this容易丢失，尤其在对象方法中传入时，需用bind、箭头函数或明确绑定
回调地狱（Callback Hell）不是写法丑，是控制流失控
嵌套三层以上回调，问题不在缩进，而在错误处理分散、无法统一中断、变量作用域混乱、调试时堆栈断裂。
- 典型症状：
error参数重复判断、每个回调都要写if (err) return handleError(err) - 不能靠“多写注释”解决，必须拆解：把深层回调抽成具名函数，用
return提前退出 - 更根本的解法是切换到
Promise链式调用，但前提是原 API 支持 Promise 化（如fs.promises.readFile）或手动包装 - 注意：用
async/await并不自动消除回调——它只对Promise生效；如果底层还是回调 API，得先封装一层new Promise
用 Promise 封装回调 API 是绕不开的基本功
很多老库（如 MongoDB 原生驱动、旧版 Redis 客户端）仍以回调为主，必须自己转成 Promise 才能用 await。
立即学习“Java免费学习笔记（深入）”；
function promisify(fn) {
return function(...args) {
return new Promise((resolve, reject) => {
fn(...args, (err, result) => {
if (err) reject(err);
else resolve(result);
});
});
};
}
// 使用
const readFile = promisify(fs.readFile);
const data = await readFile('config.json', 'utf8');- 注意错误优先（error-first）约定：回调第一个参数是
err，第二个起才是业务数据 - 有些 API 错误参数位置不固定（如某些事件监听器），不能无脑套用通用封装，得看文档
- 封装后记得保留原函数的
this绑定，否则在类方法中使用会出问题
真正卡住人的往往不是“怎么写 async”，而是搞不清某个第三方方法到底是同步返回、回调触发，还是返回 Promise——查文档时重点盯紧它的返回值类型和参数签名，别凭印象猜。
