回调地狱本身不报错，但导致错误无法集中捕获，需每层手动处理if(err)或try...catch，漏掉即静默失败；try/catch对异步回调无效，错误堆栈断裂、上下文丢失，错误传递需人工逐层中转且格式不统一，调试困难。
回调地狱本身不报错，但会让异常处理变得支离破碎——错误无法集中捕获，而是被硬塞进每一层回调里。
错误必须手动逐层检查
每个回调函数都要单独写 if (err) 或 try...catch，漏掉一层就可能静默失败。比如读取三个文件时，第二层回调忘了判错，程序就卡住或跳过后续逻辑，控制台却没报错。
- 没有统一入口捕获整个流程的异常
- 错误堆栈信息断在某一层，看不出是哪步出的问题
- 异步上下文丢失，
console.error(err)只能打印局部信息
try/catch 失效于回调内部
JavaScript 的 try/catch 只能捕获同步代码中的异常。一旦进入回调（如 setTimeout、fs.readFile、wx.request），错误就脱离了原始 try 块的作用域。
-
try { wx.request({ success: () => { throw new Error('oops') } }) }—— 这个错误根本不会被外层 catch 捕获 - 错误被抛到事件循环的下一个 tick，变成未处理的 rejection 或直接崩溃
错误传递路径断裂
在嵌套回调中，上层无法自然接收下层的错误。你得靠人工把 err 一层层往上传，稍有疏忽就会中断链路。
- 不能像
return Promise.reject(err)那样自动冒泡 - 中间层若没做
if (err) callback(err)，错误就“消失”了 - 不同 API 的错误格式不一致（有的传
err，有的用fail回调），统一处理成本高
调试时看不到完整执行流
堆栈信息只显示当前回调函数，无法还原“从哪发起、经过哪些步骤、在哪失败”的全貌。开发者得靠日志拼凑，效率低、易遗漏。
- Chrome DevTools 的 async stack trace 在深度嵌套下支持有限
- 小程序或 Node.js 环境中，错误位置常指向底层 runtime，而非业务代码行
