不建议用异常控制正常业务流程，因性能开销大、掩盖设计问题；应将可预期失败转为返回值或状态码，异常仅用于真正意外场景，并需分层定义、规范日志与处理。
Java里不建议用异常来控制正常业务流程，比如用try-catch代替条件判断、用抛异常实现逻辑跳转、或在高频调用路径中频繁抛出检查型异常。异常机制本身开销大，且会掩盖真实设计问题。
用异常替代if-else做流程判断
常见错误：为避免写多个if，把“值不存在”“参数非法”等预期情况包装成异常，再靠catch捕获处理。
- 例如：Map.get()返回null是正常语义，不该为null专门抛
IllegalArgumentException再捕获；应直接判空 - 又如：用户输入手机号格式错误，属于可预知的校验失败，应走返回错误码或封装Result对象，而非抛
RuntimeException - 原因：异常触发JVM栈遍历、填充堆栈信息，性能比普通分支差10倍以上；且调用方难以区分哪些是真异常、哪些是伪异常
在循环或高并发场景中滥用检查型异常
检查型异常（Checked Exception）强制调用方处理，但若在for循环内每次IO或转换都抛IOException或ParseException，代码会变得臃肿且难维护。
- 例如：解析1000条日志行，每行可能格式错误——应统一收集错误行并记录，而不是每错一行就抛一次异常再try-catch
- 又如：数据库批量插入时个别记录违反唯一约束，适合用
ON CONFLICT DO NOTHING或批量返回失败索引，而非逐条执行+捕获SQLException - 关键点：异常用于“意外”，不是“常见失败”。高频、可预期的失败应设计为返回值或状态码
自定义异常不区分语义，或过度包装
随便封装一个BusinessException扔到处抛，却不说明具体上下文，会让调用方无法针对性处理。
立即学习“Java免费学习笔记（深入）”；
- 避免：所有业务错误都抛同一个
MyAppException，连HTTP状态码、重试建议、日志级别都无差异 - 推荐：按场景分层，如
UserNotFoundException（404）、InsufficientBalanceException（400）、PaymentTimeoutException（504），并在构造时传入traceId和原始原因 - 注意：不要用异常传递业务数据（如把订单ID塞进message字段），应通过字段或独立对象承载
忽略异常或只打印e.printStackTrace()
这是最隐蔽也最危险的误区——吞掉异常等于隐藏系统缺陷。
- 典型反模式：
catch (Exception e) { e.printStackTrace(); }，既没记录日志级别，也没补偿动作，更没向上抛或通知监控 - 正确做法：至少用SLF4J打ERROR日志，并包含关键上下文（如用户ID、请求ID、操作类型）；对可恢复异常（如网络抖动）考虑重试；对不可恢复的，明确返回失败结果
- 特别提醒：空catch块在静态扫描工具（如SonarQube）中会被标为严重漏洞
