17370845950

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”没意义，要回答“谁、在哪儿、干了什么、为什么失败”：

• 在关键入口（如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()