Java中受检异常是继承Exception但非RuntimeException的异常，编译器强制处理；非受检异常包括RuntimeException及其子类、Error及其子类，编译器不强制处理。
明确受检异常与非受检异常的边界
Java中，受检异常（Checked Exception）是继承自Exception但不继承自RuntimeException的异常，编译器强制要求处理（try-catch或throws）；非受检异常（Unchecked Exception）是RuntimeException及其子类、以及Error及其子类，编译器不强制处理。建立检查清单前，必须统一团队对这两类异常的识别标准，避免将IllegalArgumentException误判为受检异常，或将自定义的BusinessException extends Exception遗漏为未声明受检异常。
扫描全工程异常使用模式的4个关键维度
针对每个模块/包/服务，逐项核查以下四类场景：
-
方法签名层面：检查所有public/protected方法是否在
throws子句中完整声明了抛出的受检异常；特别注意Spring @Service方法被AOP代理后，异常传播是否被意外吞没 -
调用链层面：追踪跨模块调用（如FeignClient、Dubbo接口、本地Service调用），确认上游是否感知并适配了下游抛出的受检异常；例如调用一个声明
throws IOException的工具类方法，却未捕获或声明，属于典型漏检 -
异常包装与转换层面：审查是否在日志记录、统一异常处理器（@ControllerAdvice）、或DTO转换过程中，把受检异常静默转为
RuntimeException（如new RuntimeException(e)），导致原始受检语义丢失且无法被调用方预期处理 -
资源管理层面：重点检查IO、JDBC、NIO等涉及资源释放的代码，是否用try-with-resources或finally确保关闭；若因忽略
IOException等受检异常导致资源泄漏，需在清单中标记为高危项
构建可落地的自动化+人工协同检查机制
纯人工Review效率低且易遗漏，建议分层实施：
- 用SpotBugs（含findsecbugs插件）配置规则
REC_CATCH_EXCEPTION、DE_MIGHT_IGNORE、EXC_NULL_POINTER_TO_NONNULL等，自动标记空catch、忽略异常、未处理受检异常等风险点 - 编写自定义Checkstyle规则或使用
archunit断言，例如禁止在controller层直接throws受检异常（应由统一异常处理器拦截），或禁止service方法throwsSQLException（应封装为业务异常） - 在CI流水线中嵌入检查：Maven构建时启用
-Dmaven.compiler.source=17 -Dmaven.compiler.target=17并配合maven-pmd-plugin扫描异常处理缺陷，失败则阻断发布 - 人工复查聚焦“为什么”：对每处
throws或catch标注业务含义——这个异常是否真的可能由当前上下文触发？调用方是否有合理方式恢复？是否应降级而非中断？
维护一份动态更新的团队异常规范文档
检查清单不是一次性的交付物，而是演进中的治理资产。建议包含：
立即学习“Java免费学习笔记（深入）”；
-
受检异常白名单：仅允许在特定场景使用的受检异常（如
InterruptedException在线程协作中、IOException在文件操作中），其余一律转为定制的非受检业务异常 -
异常转换映射表：例如
SQLException → DataAccessException（Spring风格）、HttpClientErrorException → ApiCallException，明确包装时机与构造参数（是否保留cause、是否添加traceId） - 各层异常处理契约：DAO层可抛受检异常；Service层只抛业务异常（非受检）；Controller层不抛异常，由全局处理器转HTTP状态码；异步任务（@Async）中未捕获异常默认丢失，必须显式记录或重抛
-
历史问题归档：记录曾因异常处理不当引发的线上故障（如某次
TimeoutException未被捕获导致线程池耗尽），作为新成员培训案例
