应避免捕获 throwable，仅限rpc入口、第三方sdk封装、全局线程处理器三类场景；中间层禁止捕获，须让异常冒泡至统一入口处理，并通过ide检查、spotbugs、阿里规范插件等工具拦截，辅以try-with-resources和前置校验替代泛捕获。
直接避免捕获 Throwable，不是靠“小心一点”，而是靠分层约束 + 工具拦截 + 替代路径设计。它真正危险的不是写错一行代码，而是让 OutOfMemoryError、StackOverflowError 这类 JVM 级崩溃被静默吞掉，程序继续跑着却状态错乱。
只在极少数受控边界才允许捕获 Throwable
绝大多数业务代码里根本不需要碰 Throwable。真要用，仅限以下三类明确意图的场景：
- RPC 或远程调用入口（如 Dubbo Filter、Feign 回调、gRPC Interceptor）：外部服务不可控，可能抛出
NoClassDefFoundError等，捕获是为了防止线程中断或连接池污染，但必须立即记录完整堆栈 + 触发熔断或降级响应 - 封装第三方黑盒 SDK 时：SDK 未声明异常契约，为防其内部抛
Error导致主线程崩，可在封装层用catch (Throwable t)统一转成业务可识别异常（如ThirdPartyUnavailableException） - 全局线程处理器：如
Thread.setDefaultUncaughtExceptionHandler，仅用于非主线程崩溃的日志归档与轻量提示，不尝试恢复
中间层一律禁止，Service/DAO/Util 不是异常终点
这些地方不是兜底的位置，而是异常传播链上的中转站：
-
catch (Throwable t)会吃掉OutOfMemoryError，内存已耗尽却还在处理请求，极易引发数据损坏或死锁 -
catch (Exception e)会一并吞掉NullPointerException、IllegalArgumentException—— 这些本该修复的逻辑缺陷，变成上线后难定位的静默失败 - 正确做法是让异常向上冒泡，由统一入口（如 Spring 的
@ControllerAdvice）做响应包装和日志记录
用工具把错误写法卡在编码阶段
靠人盯容易漏，靠机制才能落地：
- IntelliJ 中启用 inspection：“Catch Throwable” 和 “Catch Exception”，设为 error 级别，写完立刻标红
- Maven/Gradle 集成 SpotBugs，开启规则
REC_CATCH_EXCEPTION和THROWABLE_INSTANCEOF，CI 构建失败即阻断 - 安装阿里巴巴 Java 开发规范插件，它会直接提示“禁止捕获 Throwable，应使用具体异常类型”
提供更自然的替代路径，减少“不得不 catch”的冲动
很多泛捕获，其实是资源管理和输入校验没做好：
- 所有实现
AutoCloseable的资源（InputStream、Connection、HttpClient）一律用try-with-resources，自动释放，避免因finally关闭失败覆盖主异常 - 对空值、非法参数、格式错误等，优先做前置校验：
Objects.requireNonNull()、StringUtils.isBlank()、正则预匹配，而不是等NullPointerException或NumberFormatException抛出来再 catch - 解析 JSON、调用 HTTP 等高频场景，封装成
safeParseJson()、httpGetWithTimeout()等模板方法，在内部处理具体异常，对外只暴露语义清晰的业务异常
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
