异常不应用于流程控制，因其触发栈帧展开、抑制JIT优化，性能下降3–10倍；IO失败应区分可恢复场景（默认值+warn）与契约破坏；并发中锁内抛异常易致状态不一致；日志必须打印完整堆栈。
用异常做流程控制会拖慢性能
Java 异常机制底层依赖栈帧展开，throw 和 catch 的开销远高于普通分支判断。当把 NullPointerException 或自定义异常当作“返回码”来驱动业务逻辑（比如用异常表示“用户未登录”然后在上层 catch 后跳转首页），JVM 不仅要填充异常堆栈，还会抑制 JIT 优化，实测吞吐量可能下降 3–10 倍。
- 典型反例：在循环中反复
try/catch某个可能失败的解析操作，应改用Optional或预校验 - 替代方案：对可预期的业务状态（如“余额不足”“参数缺失”），直接返回
Result<t></t>或枚举状态码 - 注意：
IllegalArgumentException在构造函数或 setter 中做参数校验是合理用法，因为这是防御性编程，不是流程分支
文件/IO操作失败不等于必须抛出检查异常
IOException 是检查异常，但并非所有 IO 失败都需要向上暴露。例如读取配置文件时，若文件不存在，更合理的做法是加载默认值并记录 warn 日志，而不是强制调用方处理 IOException —— 这会让无关模块承担本不该关心的错误恢复责任。
- 关键判断点：该异常是否属于调用方有能力且应该响应的“契约破坏”？比如数据库连接中断是，而本地缓存文件缺失通常不是
- 常见误用：在工具类方法（如
FileUtils.readFileToString()）中无差别声明throws IOException，导致上层被迫写大量空catch或吞异常 - 建议：封装 IO 操作时，对可恢复、有默认策略的失败，转为运行时异常（如
IllegalStateException）或静默处理，只对真正不可控的底层故障（如磁盘满）才透出检查异常
并发场景下滥用 synchronized + 异常易引发死锁或状态不一致
在加锁代码块里抛出异常，若未妥善处理，会导致锁未释放、资源未清理、对象处于中间状态。比如在 synchronized 方法中调用外部服务，对方超时抛出 TimeoutException，此时锁已释放，但业务对象可能已部分更新。
- 典型风险：在锁内修改共享状态后、提交事务前发生异常，造成数据库与内存状态不一致
- 规避方式：把可能抛异常的操作移出同步块；或使用
try-finally确保解锁和资源释放（推荐ReentrantLock配合lock()/unlock()） - 特别注意：
wait()和notify()必须在同步块内调用，但其唤醒逻辑本身不抛异常 —— 若在此处混入网络调用等易失败操作，就是隐患源头
日志框架中捕获异常却不打印堆栈信息
很多开发者写 catch (Exception e) { log.error("处理失败"); }，这等于丢掉了最关键的问题线索。没有堆栈的错误日志，在生产环境几乎无法定位是哪行代码、什么条件触发的异常。
立即学习“Java免费学习笔记（深入）”；
- 正确写法必须包含异常对象：
log.error("处理失败", e)，否则 SLF4J 会忽略堆栈 - 避免在
catch里只打印e.getMessage()—— 它可能为空（如NullPointerException），也可能被子类覆盖失真 - 敏感场景（如支付回调）需额外记录上下文字段（订单号、用户ID），但堆栈永远是第一优先级
throws 都合理，也不是所有 catch 都必要 —— 关键看调用边界是否清晰、恢复策略是否就地可行、以及日志能否支撑快速归因。 
