不该用全局try-catch捕获RuntimeException，因其掩盖逻辑缺陷、破坏调用栈、干扰告警；应分层拦截（线程级、Web层、RPC层）+上报+自愈，仅在MQ消费者、定时任务、第三方回调等有明确恢复路径的边界入口谨慎使用。
Java高级架构中不依赖“顶层try-catch网”来兜底非受检异常——这不是推荐做法，也不具备工程可靠性。
为什么不该用全局 try-catch 捕获 RuntimeException
非受检异常（如 NullPointerException、ArrayIndexOutOfBoundsException、ClassCastException）本质是程序逻辑缺陷，不是临时性故障。强行用外层 try-catch 包裹业务主流程，只会：
- 掩盖真实 bug，让空指针在下游引发更隐蔽的错误
- 破坏调用栈完整性，日志里只剩“Exception caught at top level”，丢失原始位置
- 干扰监控告警：本该触发崩溃告警的致命问题，被静默吞掉后变成“看似正常运行”
- 与 fail-fast 原则冲突——有问题就立刻暴露，而不是延迟到某次偶然调用才浮现
真正有效的漏网异常防御机制
架构级应对非受检异常，靠的是分层拦截 + 上报 + 自愈，而非统一 catch：
- 线程级兜底：对非主线程（如异步任务、定时任务、线程池任务），设置 Thread.setDefaultUncaughtExceptionHandler，在异常未被捕获时记录完整堆栈并告警，但不尝试恢复
- Web 容器层拦截：Spring MVC 用 @ControllerAdvice + @ExceptionHandler 全局处理 Controller 层抛出的 RuntimeException，返回统一错误响应，同时记录业务上下文（如请求 ID、参数摘要）
- RPC 框架拦截：Dubbo、gRPC 等在服务端 Filter 或 Interceptor 中捕获业务方法抛出的未声明异常，转为标准错误码和可读消息，避免堆栈泄露到客户端
- JVM 错误隔离：对 Error（如 OutOfMemoryError）禁用任何 catch，而是通过 -XX:+HeapDumpOnOutOfMemoryError 和 JVM SIGQUIT 日志，配合 APM 工具（如 SkyWalking、Arthas）定位根因
哪些场景可以且应该加外层 try-catch
仅限明确可控、有恢复路径的边界入口，且必须带上下文记录：
立即学习“Java免费学习笔记（深入）”；
- 消息队列消费者方法：捕获异常后记录失败消息 ID、重试次数，决定是否进死信队列
- 定时任务 execute() 方法：防止单次执行失败导致整个调度器停摆，但需区分 transient error（如网络抖动）和 permanent error（如 SQL 语法错）
- 第三方 SDK 回调接口实现：对方要求 void 返回，你无法抛异常，此时需 try-catch 并转为日志+指标上报
核心原则没变：异常处理要靠近问题发生点，能修复就修复，不能修复就上报，绝不静默吞掉。
