别让 try-catch 成为甩锅神器：JavaScript 异常处理的实战边界与陷阱

深夜上线新功能，用户反馈页面无响应，查看控制台却一片清净。这种情况往往比红彤彤的报错更让人头大。很多时候，罪魁祸首就是被滥用或误用的 try-catch。很多开发者习惯把一大段逻辑包进去，一旦出错就默默吞掉，仿佛只要不报错，问题就不存在。但这恰恰是生产环境稳定性的隐形杀手。

理解 try-catch 的真实能力边界，是写出健壮前端应用的第一步。它并不是万能的“容错盾”。最典型的误区在于异步任务的处理。如果你在 try 块里调用了 setTimeout，里面的回调函数抛出错误，外层的 catch 根本收不到。同样，普通的 Promise 链式调用若未返回给外层，内部的拒绝状态也不会被外部 try 捕获。这种“静默失败”会直接导致数据不同步或 UI 卡死，而排查难度翻倍。

面对异步流，正确的姿势是依赖 await。当你在 try 块内使用 await 执行异步操作时，任何抛出的异常确实会被 catch 拦截。但这里埋着一个更深的坑：如果代码中混用了几处独立的异步请求，单靠局部的 try-catch 很难保证全局状态一致。此时，配置全局错误监听显得尤为关键。通过 window.addEventListener('error') 和 'unhandledrejection'，你可以构建一道兜底防线，确保那些遗漏在局部作用域之外的 Promise 拒绝或被意外抛出的运行时错误，依然能被记录到监控平台。这比事后翻日志要主动得多。

再者，错误捕获的颗粒度直接影响用户体验。将核心业务逻辑包裹在过于宽泛的 try-catch 中，虽然避免了白屏，但掩盖了真实原因。比如支付接口失败了，如果仅仅捕捉一个通用错误并提示“网络开小差了”，用户会反复尝试点击，甚至扣款成功但未到账。精准的错误分类才是正解。在网络层统一封装错误码映射，区分后端超时、参数校验失败还是服务器内部异常，再在前端给出对应的文案和操作建议。让用户知道“发生了什么”以及“该怎么办”，远比假装什么都没发生更重要。

关于错误上报，很多人只做到了 console.error。记住，开发机的控制台在生产环境是看不见的。结构化日志上报是必须的流程。捕获到的 error 对象包含堆栈信息（stack）、文件名和行号，这些是定位问题的核心证据。在 catch 块中，不仅要记录错误消息，更要保留当时的上下文变量快照（注意脱敏敏感信息）。这样当线上报警响起时，你能立刻还原事故现场，而不是对着模糊的描述猜谜。

性能方面也要留意，频繁的 try-catch 在某些旧版 V8 引擎优化下可能会有轻微开销，虽然现代浏览器已极大改善，但不代表可以无节制嵌套。更重要的是心理负担——过多的异常捕获会让后续维护者不敢轻易修改逻辑，因为不知道哪里“藏着雷”。

JS 错误处理的核心不在于消灭所有 Bug，而在于建立可观测的恢复机制。不要试图用一个 try-catch 解决所有问题，而是将其视为系统防御体系的一环：局部用于特定风险隔离，全局用于兜底监控，配套完善的日志与告警。只有当你能清晰地看到每一次“跌倒”的原因和位置，系统才能真正学会“站起来”继续运行。