java中滥用try-catch本身不影响正常路径性能，真正开销来自异常抛出、构造及堆栈填充；应减少异常创建、避免多层捕获、用@controlleradvice等声明式机制统一处理，并优先前置校验与try-with-resources资源管理。
Java 中滥用 try-catch 不会显著拖慢正常执行路径，真正影响性能的是异常被实际抛出和构造的过程。JVM 对 try 块本身做了高度优化，入口开销几乎可忽略；但每次 new 异常对象、填充堆栈（尤其是多层调用时）、序列化、日志打印，都会带来可观开销——尤其在高频场景下（如循环内、批量导入、实时计算）。
只在必要位置捕获，让异常自然向上流动
避免在每层都设 try-catch，例如 Controller → Service → Dao 层各自捕获再包装。这会导致同一异常被多次构造、多次记录、多次传递：
- Dao 层不捕获 SQLException，直接抛出原始异常或 Spring 的 DataAccessException
- Service 层仅捕获影响业务决策的异常（如库存不足），其他异常透传
- Controller 层不写任何 try-catch，交由 @ControllerAdvice 统一拦截处理
用声明式机制替代命令式兜底
把异常处理从代码块中“抽离”，转为框架级约定，既干净又高效：
- @Transactional 自动控制事务回滚，无需 service 方法里手动 try + setRollbackOnly
- @Valid + BindingResult 替代手动校验 + throw，校验失败走统一错误响应路径
- CompletableFuture.exceptionally() 或 Mono.onErrorResume() 显式处理异步异常，避免漏捕获
警惕伪容错：循环内不要无脑套 try-catch
批量处理时，在 for 循环里每条数据都包一层 try-catch 是典型性能陷阱：
- 若单条失败不影响整体（如日志上报、异步通知），catch 中只做最小动作：记录错误索引、跳过，禁止打全栈日志或远程告警
- 若需强一致性（全成功或全失败），应把整个批量操作放在一个外层 try 中，靠事务或补偿保证原子性
- 优先前置校验：用正则、非空检查、格式预筛等把可预见错误挡在执行前，大幅减少真实异常抛出次数
资源管理别靠 finally 堆叠
为防资源泄漏而在 try-catch-finally 中层层嵌套 close()，不仅易出错，还增加分支判断成本：
- 所有实现 AutoCloseable 的资源（InputStream、Connection、Statement 等）一律用 try-with-resources
- 支持多资源声明，JVM 自动按逆序关闭，即使中间抛异常也不遗漏
- 抑制异常（suppressed exception）会被自动关联到主异常，根因依然可见，无需手写 finally 处理
不复杂但容易忽略：性能损耗不在“写 try”这个动作，而在“真抛异常”和“重复兜底”。把异常当成信号而非流程分支，让它流到该处理的地方，才是轻量又健壮的做法。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
