必须重写 tostring()，因其默认返回类名@哈希码（如 com.example.user@1b6d3586），无业务信息，导致日志无效、调试困难；重写需清晰可读、含关键字段、安全处理 null、避免副作用与敏感信息泄露。
Java 中的 toString 方法在日志记录中起着关键作用：它决定了对象被直接拼接到日志字符串时呈现的内容。如果没重写，会输出类似 com.example.User@1b6d3586 这样的无意义地址，不利于排查问题；而合理重写后，能一眼看清对象关键状态。
日志中自动触发 toString 的常见场景
以下写法都会隐式调用对象的 toString()：
-
字符串拼接：如
log.info("User info: " + user); -
SLF4J 占位符外的参数：如
log.info("User: {}", user);（SLF4J 内部仍会调用user.toString()） -
Log4j2 的 {} 占位符：同理，底层依赖
toString构建日志内容
为什么默认 toString 不适合日志
Object.toString() 返回的是 类名 + @ + hashCode 的十六进制值，例如 User@3a71f4dd。这个值：
- 不包含任何业务字段信息，无法判断用户 ID、姓名或状态
- hashCode 可能重复（尤其小对象或测试环境），不具备唯一可读性
- 对调试和问题定位几乎无帮助，反而增加日志阅读成本
如何写出对日志友好的 toString
建议使用工具生成简洁、稳定、可读的实现：
- 用 Lombok 的 @ToString：自动排除敏感字段（如密码）、忽略 null 值、支持 include/exclude 控制字段范围
- 用 IDE 生成（如 IntelliJ 的 Generate → toString）：确保只包含核心业务字段（如 id、name、status），避免递归引用或大集合
-
手动编写时注意：不要在
toString中调用可能抛异常或耗时的方法（如数据库查询、远程调用）
更安全的日志记录实践
即使有良好的 toString，也建议配合日志框架特性进一步优化：
- 用结构化日志（如 Logback 的 JSON encoder 或 Log4j2 的 JSON layout），把对象字段转为 key-value，便于检索分析
- 对敏感字段（如手机号、token）在
toString中脱敏，例如显示为138****1234 - 在高并发或高频日志场景，考虑用延迟字符串化（如 SLF4J 的 lazy evaluation）避免无谓的
toString开销
不复杂但容易忽略：一个干净的 toString 是最廉价、最有效的日志可读性提升手段之一。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
