应避免用异常代替控制流、滥用检查型异常、在finally中抛异常及自定义无上下文异常；正确做法包括用分支判断替代异常控制、封装检查型异常、使用try-with-resources、提供错误码/参数/cause的自定义异常。
用异常代替控制流会拖慢程序
Java异常机制本质是栈展开（stack unwinding），抛出异常的开销远高于普通分支判断。当把IllegalArgumentException或NullPointerException当作“返回码”来控制业务走向（比如循环中反复抛/捕获来跳出逻辑），JVM无法内联、JIT优化失效，性能可能下降10倍以上。
- 典型反例：用
try/catch替代if (obj == null)做空值检查 - 更糟的情况：在高频路径（如IO解析循环、算法内层）里靠抛异常中断流程
- 替代方案：用布尔返回值、
Optional、或提前校验+明确分支
检查型异常（Checked Exception）不该强制上抛到顶层API
像IOException、SQLException这类检查型异常，如果在Service层或Controller层仍原样throws，等于把底层实现细节（比如是否用了文件存储、是否连了数据库）暴露给调用方，破坏封装性，也迫使上层写一堆无意义的try/catch。
- 常见错误：DAO方法声明
throws SQLException，Service层又直接throws它，Web层再catch转成HTTP 500 - 合理做法：在数据访问层就捕获并转为运行时异常（如自定义
DataAccessException），或统一用RuntimeException包装 - 例外场景：确实需要调用方显式处理（如文件不存在时走默认配置），才保留检查型异常，但必须配清晰文档
不要在finally里抛异常覆盖原始异常
如果finally块里执行关闭资源等操作时抛出新异常（比如close()触发IOException），它会吞掉try块里原本的异常，导致真正出问题的地方被掩盖——这是调试时最让人抓狂的问题之一。
- 错误写法：
finally { resource.close(); }（close()可能抛异常） - 安全写法：用
try-with-resources，或在finally里用if (resource != null) try { resource.close(); } catch (IOException ignored) {} - 关键点：JVM只保留最后一个未捕获的异常；原始异常的堆栈信息一旦丢失，基本无法定位根因
自定义异常不带业务上下文等于没写
只继承Exception或RuntimeException，却不重写getMessage()、不提供构造参数、不包含关键字段（如错误码、失败ID、请求参数快照），这个异常对排查问题几乎没用。
立即学习“Java免费学习笔记（深入）”；
- 无效示例：
new BusinessException("操作失败") - 有效示例：
new BusinessException(ErrorCode.USER_NOT_FOUND, "userId=" + userId, cause) - 必须包含：唯一错误码（用于日志聚合）、可读描述（含变量值）、原始异常引用（
cause）、必要时加toString()输出关键状态
throws Exception签名，或为了“看起来健壮”而层层包装。最难改的，其实是那些藏在工具类里、用catch (Exception e) { throw new RuntimeException(e); }粗暴兜底的逻辑。 
