Java中不该用异常代替控制流或状态返回：参数校验、业务规则失败、高频路径等场景滥用异常会导致性能下降、可读性差、调试困难及协作成本上升，应优先使用if判断、Optional或统一响应封装。
Java里不该用异常的地方，比该用的地方更值得警惕——异常不是控制流，也不是状态返回方式，滥用它会让代码变慢、难读、难调试。
用 if 能判断的，就别抛 RuntimeException
比如参数校验、空值检查、范围判断，这些本该是前置防御逻辑，不是“异常情况”。用异常代替 if 不仅掩盖了设计意图，还会拖慢性能（创建异常对象要收集完整堆栈）。
- ❌ 错误示范：把空值当异常处理
public void processUser(User user) {
if (user == null) {
throw new IllegalArgumentException("user cannot be null");
}
// ...业务逻辑
}
- ✅ 正确做法：提前拒绝 + 明确语义
public void processUser(User user) {
Objects.requireNonNull(user, "user must not be null");
// ...业务逻辑
}
- 性能影响：
IllegalArgumentException构造开销约是普通if判断的 10–50 倍（取决于堆栈深度） - 可读性陷阱：调用方看到
throws IllegalArgumentException，会误以为这是“偶发错误”，而其实是“你传错了”
业务规则不满足时，慎用检查型异常（Checked Exception）
像“余额不足”“订单已取消”“用户未实名”这类业务规则失败，本质是正常流程分支，不是系统失常。强制要求上层 try-catch 或 throws，只会让 API 变得笨重、调用链污染严重。
- ❌ 常见反模式：为每个业务拒绝定义一个
InsufficientBalanceException extends Exception - ✅ 更合理方案：用自定义非检查异常 + 统一响应封装（如 Spring 的
@ControllerAdvice） - 兼容性风险：如果未来要把这个接口暴露为 RPC 或 HTTP API，检查型异常无法跨语言传递，反而要额外做映射层
循环体或高频路径中，绝对避免抛异常
在 for 循环、Stream 处理、IO 缓冲区解析等每秒执行成千上万次的代码路径里，抛异常等于主动引入性能瓶颈。JVM 对异常路径的 JIT 优化极弱，且每次都会触发堆栈填充。
立即学习“Java免费学习笔记（深入）”；
- ❌ 危险示例：用
Integer.parseInt()解析大量字符串，靠捕获NumberFormatException来判断是否为数字 - ✅ 替代方案：用正则预检，或 Apache Commons 的
NumberUtils.isCreatable()，或 Java 17+ 的Integer.tryParseInt()（返回Optional） - 真实影响：在吞吐量 10k QPS 的服务中，单次
NumberFormatException抛出可能增加 0.2–0.5ms 延迟，积少成多直接拖垮 RT99
最常被忽略的一点：异常的语义边界一旦模糊，团队协作成本就指数上升。比如同一个 BusinessException 既代表“库存扣减失败”，又代表“短信网关超时”，下游根本没法区分是重试、降级还是告警。真正健壮的异常设计，不是“有没有异常”，而是“每个异常是否只说一件事”。
