应捕获checked exception并合理恢复或声明throws，不主动catch unchecked exception除非能就地恢复；用try-with-resources确保资源关闭；自定义异常依场景选继承Exception或RuntimeException；日志必须输出完整异常对象。
Java中checked exception和unchecked exception到底该不该捕获
Java异常分为checked exception（如IOException、SQLException）和unchecked exception（即RuntimeException及其子类，如NullPointerException、IllegalArgumentException）。关键判断标准不是“能不能捕获”，而是“调用方是否能合理恢复”。
常见错误是把RuntimeException层层try-catch再printStackTrace()——这掩盖了本应暴露的编程错误；更糟的是，对IOException不做任何处理，直接抛给上层又不声明throws，导致编译失败或逻辑断裂。
-
checked exception：必须处理。要么catch后做有意义的补偿（如重试、降级、记录上下文后转为业务异常），要么在方法签名中明确throws -
unchecked exception：原则上不主动catch。除非你能在当前作用域完成恢复（例如解析JSON失败时返回默认对象），否则应让其向上冒泡，由全局异常处理器统一记录+响应 - 绝不使用
catch (Exception e)吞掉异常——它会同时捕获本该崩溃的RuntimeException和真正需要处理的checked exception，失去类型语义
如何正确使用try-with-resources避免资源泄漏
手动在finally里close()不仅冗长，还容易因close()本身抛异常而掩盖原始异常。Java 7引入的try-with-resources是标准解法，但有几个硬性前提：
- 资源类必须实现
AutoCloseable接口（Closeable是其子接口，也满足） - 不要在
try块内对资源变量重新赋值，否则编译器无法保证关闭的是初始对象 - 多个资源用分号分隔，关闭顺序与声明顺序相反（后声明的先关闭），这对有依赖关系的资源很重要（如先关
BufferedWriter再关FileOutputStream）
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedInputStream bis = new BufferedInputStream(fis)) {
// 使用bis读取
} catch (IOException e) {
// 异常处理
}
自定义异常该继承Exception还是RuntimeException
核心看这个异常是否属于“可预期且调用方有能力处理”的场景。比如支付失败，可能是余额不足、风控拦截、渠道超时——这些都该设计成不同的RuntimeException子类（如InsufficientBalanceException），因为业务代码可以针对性地跳转到充值页、提示用户、发起重试。
反例是把所有自定义异常都继承Exception，结果每个调用点都得写throws或try-catch，徒增模板代码，却没带来实际恢复能力。
- 继承
RuntimeException：用于业务规则违反、非法参数、系统状态不一致等“程序不该走到这里”的情况 - 继承
Exception：仅当外部系统/协议强制要求调用方必须显式应对某种失败（如银行联机交易返回特定错误码需走人工核验流程） - 所有自定义异常务必提供带
String message和Throwable cause的构造函数，方便包装原始异常
log.error()里只打e.getMessage()是严重错误
线上排查最怕看到log.error("文件读取失败: {}", e.getMessage())——它丢掉了堆栈、丢失了异常类型、抹平了原始原因。一旦发生嵌套异常（比如IOException被包装成ServiceException），只打getMessage()就等于放弃所有线索。
正确做法永远是传入完整异常对象：
try {
processFile();
} catch (IOException e) {
log.error("处理文件 {} 失败", fileName, e); // 第三个参数传e
}
还要注意：不要在catch块里先e.printStackTrace()再log.error()——控制台输出不可控、无格式、难聚合，日志系统才是唯一可信出口。
复杂系统里异常可能跨线程、跨服务传播，这时候cause链和唯一traceId比异常名重要得多。别省那几行日志配置。
