Java异常日志需保留完整堆栈、脱敏敏感信息、区分error/warn级别、补充业务上下文（如traceId、用户ID）、禁用e.printStackTrace()等反模式，确保可追溯与安全。
Java中记录异常日志，核心是保留完整上下文、避免敏感信息泄露、区分日志级别、统一格式，而不是简单调用logger.error("xxx", e)就完事。
用正确的日志级别和参数格式记录异常
不要把异常对象转成字符串拼接（如e.toString()或e.getMessage()），这会丢失堆栈；也不要只打消息不打异常对象。正确做法是：
- 使用
logger.error("业务操作失败，用户ID：{}，订单号：{}", userId, orderId, e)——异常对象e必须放在参数列表末尾，SLF4J/Logback才能自动提取完整堆栈 - 普通警告或预期异常（如参数校验失败）用
warn，非预期运行时错误（如空指针、数据库连接中断）才用error - 避免在
info或debug里打印完整异常堆栈，除非用于临时排查
脱敏敏感数据，不记录密码、密钥、身份证、银行卡等
日志可能被运维、外包甚至攻击者看到，明文记录敏感字段是高危行为：
- 记录前对日志内容做简单清洗，例如用正则替换手机号
1[3-9]\\d{9}为1XXXXXXXXX，或用工具类统一过滤 - 不要在异常消息中拼接敏感值：
"用户" + user.getPassword() + "登录失败"→ 改为"用户登录失败（ID: {}）" - 数据库SQL异常默认含参数值？配置MyBatis或JDBC驱动关闭
show_sql或启用logSqlWithParams=false等安全选项
补充业务上下文，让日志可追溯
单看“NullPointerException”没意义，要回答“谁、在哪儿、干了什么、为什么失败”：
立即学习“Java免费学习笔记（深入）”；
- 在关键入口（如Controller、Service方法开头）打
debug日志，记录入参摘要（脱敏后）、请求ID（如TraceId）、用户身份 - 捕获异常时，用
new RuntimeException("支付回调验签失败", e)包装并添加业务语义，比原始SignatureException更易理解 - 使用MDC（Mapped Diagnostic Context）注入线程级上下文，例如
MDC.put("traceId", request.getHeader("X-Trace-ID"))，确保整条链路日志带相同标识
避免常见反模式
这些写法看似省事，实则增加排查成本：
- ❌ e.printStackTrace() —— 输出到控制台，不进日志系统，无法集中收集和告警
- ❌ catch后空处理（吞异常） —— 尤其在finally块里又抛新异常，导致原始根因丢失
- ❌ 在循环里高频打error日志 —— 一次异常打1000条日志，压垮日志系统；应聚合统计或限流输出
-
❌ 把异常当流程控制 —— 如用
FileNotFoundException判断文件是否存在，应改用Files.exists()
