java异常处理核心是：异常仅用于真正异常场景，禁用作流程控制；检查型异常处理可恢复外部问题，运行时异常须前置校验规避；高频路径避免抛异常，敏感操作需显式失败反馈与安全兜底。
Java异常处理不能只图代码简洁或一味吞掉异常，关键是在性能敏感路径上避免滥用异常机制，同时确保安全边界不被绕过。核心原则是：异常用于真正异常的情况，而非流程控制；敏感操作必须有明确的失败反馈和防护兜底。
异常分类要清晰，运行时与检查型各司其职
检查型异常（Exception及其子类，除RuntimeException外）强制调用方处理，适合可预期、需恢复的外部问题，比如文件不存在、网络超时。运行时异常（RuntimeException及其子类）代表程序逻辑错误，如空指针、数组越界，不应被捕获后静默吞掉，而应通过校验前置规避。
- 对IO、数据库、HTTP等外部依赖，优先用检查型异常或封装成业务异常，让调用方决定重试、降级或告警
- 禁止用try-catch包裹大量正常逻辑来“代替if判断”，例如用catch NumberFormatException代替String.matches("\d+")校验数字格式
- 自定义异常建议继承RuntimeException（无检查压力）或Exception（需强制处理），但不要混用——同一模块内异常语义要统一
高性能场景下，避免在循环或高频路径中抛异常
异常对象创建、堆栈填充、JVM解析开销显著高于普通对象。在日志解析、JSON反序列化、协议编解码等高频环节，应优先使用预校验+返回值模式替代异常驱动流程。
- 例如解析时间字符串：先用DateTimeFormatter.parseUnresolved()试探，成功再构建对象；而不是直接parse()然后捕获DateTimeParseException
- 集合取值前用containsKey()或isEmpty()判断，而非依赖get()返回null后抛NPE再捕获
- 若必须抛异常（如参数非法），确保只在入参校验失败时发生一次，不在内部循环中重复触发
安全兜底不可少，敏感操作必须显式失败反馈
涉及权限校验、资金操作、数据删除等动作，绝不能因异常未捕获导致“静默跳过”。即使上层忽略异常，也要通过日志、监控、事务回滚等方式留下痕迹。
立即学习“Java免费学习笔记（深入）”；
- 所有service方法入口加@Valid或手动校验DTO，非法参数立即抛IllegalArgumentException并记录warn日志
- 数据库更新后检查updateCount == 0，补抛OptimisticLockException或DataNotFoundException，防止“更新了0行却认为成功”
- 涉及密码、token、密钥的操作，异常中严禁打印原始值，日志脱敏用"***"代替，且异常消息不暴露内部结构（如不写“BCrypt hash长度不足60”）
异常链路要可追溯，但别过度包装
保留原始异常的cause很重要，但每层都new RuntimeException(e)会丢失上下文信息。推荐用构造函数带message+cause的方式增强可读性，而非无意义嵌套。
- 底层抛出IOException，中间层可包装为StorageException("上传文件到OSS失败", e)，既说明业务含义，又保留根因
- 避免连续三层都做类似包装，导致getCause().getCause().getCause()才能看到原始异常
- 异步线程、定时任务、Filter拦截器中发生的异常，务必用统一异常处理器捕获并上报，不能任其丢失
基本上就这些。异常不是bug的遮羞布，也不是性能的绊脚石——用对地方，它就是系统稳定和安全的守门人。
