异步javascript是让浏览器在等待耗时操作时不阻塞主线程，回调函数易致嵌套缩进、错误难捕获、调试堆栈断裂；promise和async/await更优，但fs.readfile等旧api仍需回调，可用util.promisify或手动封装。
异步 JavaScript 不是“等一会儿再执行”，而是让浏览器在等待某个耗时操作（比如网络请求、文件读取）完成时，不卡住主线程，继续处理其他任务。回调函数只是其中一种处理方式，但容易陷入“回调地狱”，现代开发中已不推荐作为首选。
回调函数为什么容易出问题
回调函数本身没有错，错在嵌套使用时的可维护性与错误处理能力。典型表现是多层缩进、错误无法集中捕获、逻辑难以复用。
-
fetch返回Promise，但如果你强行用callback封装它，反而绕过原生错误链路 - 多个异步操作顺序依赖时，
callback(err, data)的err必须每层手动检查，漏一个就静默失败 - 调试时堆栈信息被截断，报错位置显示在
setTimeout或事件循环底层，而不是你写的业务逻辑里
什么时候还必须用回调函数
不是所有 API 都支持 Promise 或 async/await。Node.js 早期 API（如 fs.readFile）、某些浏览器 API（如 requestIdleCallback）、或第三方库的底层接口，仍以回调形式暴露。
- Node.js 的
fs.readFile原生只接受(err, data) => {}形式，必须写回调；但可用fs.promises.readFile替代 -
addEventListener的第二个参数必须是函数，这是事件机制决定的，但它本身不是“异步流程控制”，别和Promise混为一谈 - 某些 C++ 插件或 WebAssembly 模块导出的 JS 接口，只提供回调签名，此时需老老实实处理
error和success分支
用 Promise 包装回调函数的实际写法
核心原则：只要回调函数有明确的成功/失败路径（通常是 (err, result) => {}），就能转成 Promise。不要自己 new Promise 包一层就完事，要确保拒绝（reject）时机准确。
立即学习“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);
readFile('config.json', 'utf8')
.then(JSON.parse)
.catch(err => console.error('解析失败:', err));
- 注意判断
err是否为真值，有些 API 会传null或undefined表示成功 - 如果原始回调是“单次触发但无 error 参数”（如
setTimeout(cb, ms)），直接resolve()即可，不用reject - Node.js 14+ 可直接用
util.promisify，但需确认目标函数符合 Node.js 回调规范（最后参数是(err, ...)）
真正难的不是怎么写回调，而是判断该不该用回调——大多数时候，你应该先查文档：这个 API 有没有 Promise 版本？有没有 AbortSignal 支持？有没有内置重试或超时？这些比手写回调健壮得多。
