Java异常日志怎么记录更合理

文章不知道大家是否熟悉？今天我将给大家介绍《Java异常日志如何合理记录》，这篇文章主要会讲到等等知识点，如果你在看完本篇文章后，有更好的建议或者发现哪里有问题，希望大家都能积极评论指出，谢谢！希望我们能一起加油进步！

日志必须完整记录异常堆栈、显式拼接业务上下文、合理区分error/warn级别、严格脱敏敏感信息。正确写法：log.error("msg", e)；禁用e.getMessage()或e.toString()；MDC需手动复制与清理；异步任务须传递上下文；敏感字段须调用脱敏工具。

异常堆栈必须完整记录，不能只打 getMessage()

很多同学在 catch 块里只写 log.error(e.getMessage())，结果线上出问题时完全看不到哪行代码抛的异常、参数是什么、调用链怎么走的。Java 的 Throwable 对象自带完整堆栈，日志框架（如 Logback、Log4j2）只要传入 Exception 实例本身，就能自动展开。

• ✅ 正确写法：log.error("用户支付失败", e)（第二个参数是 Throwable）
• ❌ 错误写法：log.error("用户支付失败: " + e.getMessage())（丢弃堆栈）
• ⚠️ 注意：e.toString() 也不行，它只包含类名+消息，没有堆栈行号

业务上下文要显式拼进日志消息，别依赖 MDC 自动注入

MDC（Mapped Diagnostic Context）看着方便，但容易漏设、错设、跨线程失效。比如异步线程没手动 MDC.copy()，或者 filter 里没清理，会导致后续请求日志混入旧 traceId。

• 显式拼接更可控：log.error("支付失败[orderNo={} userId={} amount={}]", orderNo, userId, amount, e)
• 如果用 MDC，务必在入口（如 Spring Filter）设 MDC.put("traceId", ...)，并在 finally 中 MDC.clear()
• 异步任务（如 @Async、线程池）必须手动 MDC.getCopyOfContextMap() 并在子线程还原

区分 error 和 warn：可恢复的异常用 warn，不可恢复的才 error

不是所有 catch 都该记 error 级别。比如调第三方接口超时后自动重试成功了，记 error 会污染告警指标；而空指针或数据库连接彻底断开，才是真正需要人工介入的 error。

• IOException（网络/IO 类）：多数情况应先 warn + 重试逻辑，连续失败再升 error
• IllegalArgumentException / NullPointerException：通常是代码缺陷，直接 error
• BusinessException（自定义业务异常）：按语义决定级别，例如“余额不足”是预期业务流，warn 即可

敏感信息必须脱敏，日志里不能出现明文密码、身份证、银行卡号

曾经有项目把 e.printStackTrace() 直接写进文件，结果用户手机号和 token 全量泄露。Java 异常本身不会带敏感字段，但你在日志消息里拼的变量可能带。

• 禁止在日志中拼接原始请求体、headers、token 字符串
• 使用工具类统一脱敏：DesensitizationUtil.idCard(idCard)、DesensitizationUtil.mobile(mobile)
• 配置日志框架的 PatternLayout 时，避免用 %ex（全堆栈）而不用 %throwable —— 二者等价，重点是别在消息里自己加敏感内容

log.warn("短信发送失败[phone={} templateId={}]", DesensitizationUtil.mobile(phone), templateId, e);

日志不是记流水账，是给下一次故障排查留线索。堆栈完整性、上下文明确性、级别合理性、数据安全性——这四点里漏掉任何一项，都可能让一个本可快速定位的问题拖上几小时。

终于介绍完啦！小伙伴们，这篇关于《Java异常日志怎么记录更合理》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！