catch(Exception e) 危险因吞掉空指针等代码缺陷异常，掩盖bug致线上难定位；应捕获具体类型或用catch(Throwable t)打全量日志后重抛。
为什么 catch(Exception e) 是危险的默认写法
它会吞掉本该暴露的编程错误，比如 NullPointerException 或 ArrayIndexOutOfBoundsException，这些根本不是“业务异常”，而是代码缺陷。你 catch 住它们，等于告诉 JVM：“这个空指针没问题，继续跑。”结果是 bug 被掩盖，问题延迟到更奇怪的地方爆发。
典型现象：本地测试一切正常，上线后某天某个接口突然返回空数据或 500，日志里只有一行被吞掉的 Exception，没堆栈、没类型、没法定位。
- 只在明确知道要统一兜底且有日志+监控补救时才用
catch(Exception e)，比如全局异常处理器顶层 - 业务逻辑层、DAO 层、Service 方法内部，必须捕获具体异常类型
- 如果真不确定可能抛什么，先
catch(Throwable t)打全量日志再 rethrow，而不是静默吞掉
try-catch-finally 和 try-with-resources 怎么选
核心区别不在语法糖，而在资源生命周期控制是否可靠。finally 块里手动 close() 容易漏判 null、容易被异常打断、容易写错顺序；try-with-resources 则由 JVM 保证：只要实现了 AutoCloseable，哪怕 try 块里抛了异常，资源也一定被关闭，且按声明逆序关闭。
常见错误：用 finally 写了两遍 close()，或者在 close() 里又抛新异常，把原始异常盖掉了。
立即学习“Java免费学习笔记（深入）”；
- 所有 JDK 7+ 的 IO 类（
FileInputStream、BufferedReader）、JDBC 接口（Connection、Statement、ResultSet）都支持try-with-resources - 自定义资源类必须实现
AutoCloseable，且close()方法不能抛受检异常（否则得再套一层 try） - 不要在
try-with-resources的资源声明里调用可能返回 null 的工厂方法，否则触发NullPointerException在进入 try 前就崩了
受检异常（Checked Exception）到底要不要声明 throws
不是“要不要”，而是“谁该负责”。Java 强制你处理 IOException、SQLException，是因为它们代表外部不确定性（磁盘满、网络抖动、DB 连接断），调用方必须意识到风险并决策——重试？降级？转成运行时异常向上抛？
滥用 throws 的后果：一层层往上甩锅，最后全堆在 Controller 层，导致业务逻辑和异常处理混在一起，可读性归零。
- DAO 层遇到
SQLException，应该包装成自定义的DataAccessException（运行时异常），避免上层被迫写一堆无意义的 try-catch - 工具类方法（如解析 JSON）若用
JsonProcessingException，建议直接抛出，因为调用方大概率需要根据解析失败原因做不同处理 - 如果确定异常永远不该由当前层处理（比如配置加载失败意味着系统无法启动），就用
RuntimeException包装后立即 throw，别 throws
日志记录异常时，e.printStackTrace() 为什么是错的
它把堆栈打到标准错误流，绕过日志框架，既没上下文（traceId、用户ID、请求路径），也没级别控制，更没法对接 ELK 或 Sentry。线上出问题时，你连这条日志属于哪个请求都不知道。
另一个坑：只记 e.getMessage()，丢掉堆栈——等于只记“用户名为空”，不记“空值来自哪行代码、哪个参数、什么调用链”。
- 一律用日志框架的
error("msg", e)形式，例如log.error("Failed to send email to {}", user.getEmail(), e) - 敏感信息（密码、token、银行卡号）必须脱敏后再进日志，不要依赖异常消息本身是否含敏感字段
- 异步线程里抛异常，务必显式捕获并打日志，否则堆栈直接消失，连“哪里崩了”都找不到
Exception 在不同层代表完全不同的事，而人总想用一个 catch 解决所有问题。 
