回调本身不是需处理对象，而是异步完成时被调用的函数；真正问题是回调地狱、错误传递混乱和可读性差；Promise和async/await可解决控制流断裂与错误捕获难题。
JavaScript 异步编程中，回调（callback）本身不是“需要被处理”的对象，而是你主动传入、由异步操作在完成时调用的函数。真正要解决的，是回调带来的嵌套、错误传递混乱和可读性问题——也就是常说的“回调地狱”。
为什么直接写回调容易出错
手动管理回调最常踩的坑不是语法错误，而是控制流断裂：
-
setTimeout或fs.readFile的回调里忘了return，后续逻辑意外执行 - 错误没统一捕获：
if (err) return callback(err)漏写一次，整个链路就静默失败 - 多个并行异步操作时，靠手动计数判断完成（如
done++ === 3），极易因某次调用被跳过或重复触发而卡死 - 无法用
try/catch捕获回调里的同步异常，更捕获不到异步抛出的错误
用 Promise 封装回调函数是最低成本升级
几乎所有 Node.js 核心模块（fs、dns）和浏览器 API（fetch、setTimeout）都支持 Promise 化。别自己手写 new Promise((resolve, reject) => {...}) 封装，优先用现成方案：
- Node.js 14+ 直接用
util.promisify：const { promisify } = require('util');
const readFile = promisify(fs.readFile);
readFile('./config.json', 'utf8')
.then(data => JSON.parse(data))
.catch(err => console.error('解析失败:', err)); - 浏览器中封装
setTimeout：const delay = ms => new Promise(resolve => setTimeout(resolve, ms));
delay(1000).then(() => console.log('1秒后执行')); - 不要为每个回调都写
Promise，只封装你真正要组合使用的部分
async/await 不是语法糖，它改变了错误传播路径
async/await 让你用同步写法表达异步逻辑，但关键在于：它让 try/catch 第一次真正能捕获异步错误。
立即学习“Java免费学习笔记（深入）”；
- 下面这段代码中，
JSON.parse抛异常会被catch捕获：async function loadConfig() {
try {
const data = await fs.promises.readFile('./config.json');
return JSON.parse(data);
} catch (err) {
// 这里能同时捕获文件读取失败和 JSON 解析失败
throw new Error(`配置加载失败: ${err.message}`);
}
} - 但注意：
await只解包一层 Promise，如果JSON.parse返回的是另一个 Promise，你得再await一次 -
await后面如果不是 Promise，会自动包装成Promise.resolve(value)，所以await 42是合法的
回调还没消失，只是藏得更深了
你仍然会在某些场景下碰到回调：事件监听（addEventListener）、Stream 处理（stream.on('data', ...)）、第三方库（如 redis.client.get(key, callback)）。这时别硬套 async，而是明确它的角色：
- 它不是“主流程”，而是“响应式钩子”——不参与返回值链，只做副作用（打日志、更新 UI、发请求）
- 如果必须把回调转成 Promise（比如等某个事件触发一次），用
once（Node.js）或手动new Promise+removeEventListener，但仅限必要时 - 永远检查文档：Redis 有
getAsync，MongoDB 驱动默认返回 Promise，别一上来就写回调
真正的难点不在语法转换，而在判断哪部分逻辑该串行、哪部分该并发、错误该在哪个层级聚合。回调只是暴露了这些问题，而不是造成它们的原因。
