回调函数导致嵌套过深、错误处理分散、无法用return中断、调试困难、破坏线性控制流、闭包问题、异常捕获困难、组合异步任务复杂、缺乏统一错误传播机制。
回调函数会导致嵌套过深（“回调地狱”）
当多个异步操作需要串行执行时，回调函数会逐层嵌套，代码缩进越来越深，可读性和维护性急剧下降。比如连续读取三个文件，每一步依赖上一步结果，就会写成 fs.readFile 套三层甚至更多。
- 错误处理分散：每个回调里都要单独写
if (err)分支，重复且易遗漏 - 无法用
return中断流程：在内层回调里return只退出当前函数，不影响外层逻辑 - 调试困难：堆栈信息被截断，出错时难以定位原始调用位置
回调函数破坏了线性控制流
同步代码天然按书写顺序从上到下执行，而回调函数把后续逻辑“扔”到事件循环队列里，导致实际执行顺序与代码视觉顺序不一致。这会让开发者误判执行时机，尤其在涉及变量作用域、状态更新时容易出错。
-
for循环中直接使用循环变量（如i）传入回调，常因闭包问题拿到错误的值 - 无法用
try...catch捕获异步回调里的异常，必须靠回调参数中的err显式传递 - 难以组合多个异步任务（如并发执行、竞速、降级），需手动管理状态标记和计数器
回调函数缺乏统一的错误传播机制
Node.js 风格的回调约定是 callback(err, result)，但这个约定不是语言强制的，不同库可能用不同签名（比如有的先传 result），也没有标准方式让错误自动向上冒泡。
- 一旦某个中间回调忘记检查
err，错误就静默丢失 - 无法像
Promise.catch()或try...catch那样集中处理所有层级的异步错误 - 第三方库若未严格遵循错误优先约定，集成时容易引发不可预期的行为
fs.readFile('a.txt', (err, dataA) => {
if (err) throw err;
fs.readFile('b.txt', (err, dataB) => {
if (err) throw err;
fs.readFile('c.txt', (err, dataC) => {
if (err) throw err;
console.log(dataA, dataB, dataC);
});
});
});
回调地狱不是理论问题，是真实项目中高频出现的维护负担。哪怕只多加一层嵌套，排查成本就明显上升。现代 JavaScript 的 async/await 和 Promise 就是为解决这些结构性缺陷而设计的——它们不改变异步本质，但重构了表达方式。 
