企业级开发中应严格限制捕获throwable：仅在rpc/远程调用入口、第三方sdk封装层、全局线程处理器等受控边界使用，且需记录堆栈并熔断降级；普通业务层必须禁用，改用具体异常类型或交由@controlleradvice统一处理。
在企业级开发中，捕获 Throwable 往往不是为了“兜底”，而是埋下隐患。它会一并吞掉 Error（如 OutOfMemoryError、NoClassDefFoundError），而这些错误本不该被业务代码处理——它们代表 JVM 层面的崩溃或资源耗尽，强行捕获反而掩盖严重问题，干扰监控告警和故障定位。
明确分层：哪些地方可以捕获 Throwable
仅在极少数受控边界处允许捕获 Throwable，且必须有清晰意图和配套措施：
-
RPC 或远程调用入口：比如 Dubbo Filter、Feign Client 回调、gRPC 的 interceptors。外部服务不可控，可能抛出
Error，此时捕获Throwable是为防止线程中断或连接池污染，但需立即记录完整堆栈并触发熔断/降级； -
第三方 SDK 封装层：调用未提供异常契约的黑盒 SDK 时，用
Throwable包裹调用，并统一转为可识别的业务异常（如ThirdPartyServiceUnavailableException）； -
全局线程异常处理器：如
Thread.setDefaultUncaughtExceptionHandler，用于兜住非主线程的致命崩溃，仅做日志归档与进程保活提示，不尝试恢复。
普通业务代码必须禁用 Throwable 捕获
Controller、Service、DAO 等常规业务层，一律禁止 catch (Throwable t) 或 catch (Exception e) 这类宽泛捕获：
- 用具体异常类型替代，例如
catch (SQLException e)、catch (JsonProcessingException e)，确保每个分支都有明确语义和处理逻辑； - 对运行时异常（如
NullPointerException、IllegalArgumentException），优先通过参数校验、空值防护等手段前置规避，而非依赖 catch； - 若真遇到无法归类的异常，应让其向上冒泡至统一异常处理器（如 Spring 的
@ControllerAdvice），由框架层做兜底响应，而不是在业务方法里自行吞掉。
用编译期和工具链守住底线
单靠规范难以杜绝误用，需结合工程化约束：
- 在静态检查工具（如 SonarQube、Alibaba Java Coding Guidelines）中启用规则
java:S1181（禁止捕获 Throwable）和java:S1166（禁止空 catch 块），CI 阶段直接阻断； - 在基础 SDK 或内部 starter 中封装安全的远程调用模板，把
Throwable捕获逻辑收口到内部，对外只暴露声明式异常（如throws RemoteCallFailureException）； - 在日志系统中配置告警：当出现
ERROR级别日志含java.lang.Error关键字，且堆栈中存在业务包路径时，自动通知架构组核查是否误捕获。
替代方案：用更健壮的容错机制代替捕获
真正需要“兜底”的场景，应转向设计层面的容错，而非异常捕获：
- 对关键外部依赖，引入熔断器（如 Sentinel、Resilience4j），失败时走 fallback 逻辑，而非靠 try-catch 拦截；
- 对数据一致性要求高的操作，使用 Saga 模式或本地消息表，把异常转化为可重试、可补偿的状态机步骤；
- 对内存敏感任务，通过 JVM 参数（
-XX:+ExitOnOutOfMemoryError）主动退出，配合 K8s 自愈能力重启实例，比静默吞掉 OOM 更可靠。
