应直接将异常对象作为参数传给日志方法，如 logger.error("订单处理失败", e)，而非拼接消息或调用 printStackTrace()，以确保完整堆栈被记录且可追溯。
在 Java 中记录异常堆栈信息，关键不是只打印异常消息（e.getMessage()），而是用日志框架的专用方法传入异常对象本身，让框架自动输出完整堆栈跟踪（stack trace）。
用 logger.error() 传入 Throwable 参数
主流日志框架（如 Logback、Log4j2、SLF4J 绑定实现）都支持在日志方法中直接传入 Throwable 实例。这是记录堆栈最标准、最可靠的方式：
- ✅ 正确写法：调用
logger.error("订单处理失败", e)—— 第二个参数是Exception对象 - ❌ 错误写法：
logger.error("订单处理失败: " + e.getMessage())或logger.error("订单处理失败", e.toString())—— 堆栈丢失
这样记录后，日志中会同时包含你写的提示文本和完整的多行堆栈（包括类名、方法、行号、嵌套异常等），排查时能准确定位到出问题的代码行。
避免手动调用 printStackTrace()
e.printStackTrace() 会把堆栈输出到 System.err，不经过日志框架，导致：
- 无法统一配置输出格式、级别、目标（文件/远程/异步）
- 不能按包或类过滤，不利于线上问题收敛
- 可能干扰标准日志结构（比如 JSON 日志里混入纯文本堆栈）
除非调试阶段临时加断点查看，否则生产代码中应完全避免 printStackTrace()。
捕获异常后不要“吞掉”再空抛
常见反模式：
try {
doSomething();
} catch (IOException e) {
logger.error("读取配置失败"); // ❌ 没传 e，堆栈消失
throw new RuntimeException("配置加载异常"); // ❌ 新异常无原始堆栈
}
改进方式：
- 保留原始异常：用
throw new RuntimeException("配置加载异常", e)（带 cause 构造） - 日志中同步记录：在
catch块里写logger.error("读取配置失败", e)
这样既留痕又保栈，链路可追溯。
注意日志级别和敏感信息
堆栈通常含变量值、路径、内部类名等，记录时需权衡：
- 推荐用
error或warn级别记录异常堆栈（info/debug级别一般不记） - 若堆栈里可能泄露密码、token、用户身份证等，可在日志框架中配置脱敏规则（如 Logback 的
PatternLayout配合自定义Converter），或在捕获后做预处理（谨慎使用）
不复杂但容易忽略：只要把异常对象当参数传进去，框架就帮你搞定堆栈输出。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
