tostring未生效的根本原因是未在实际运行对象的类中正确重写，或对象真实类型未重写该方法；需检查重写位置、实例类型、lombok配置及避免副作用。
toString 方法没生效，打印出来还是类名加哈希值
这是最常见的现象：你重写了 toString，但用 System.out.println(obj) 或日志输出时，看到的仍是类似 com.example.User@1f23b2a。根本原因只有两个：toString 没被正确重写，或重写的不是当前实际运行的对象类型。
- 检查是否在目标类里重写了
toString—— 而不是父类、工具类或某个同名但无关的方法 - 确认对象实例的真实类型：如果变量声明为父类或接口（如
Object obj = new User();），但User没重写toString，就会调用Object.toString() - 留意 IDE 自动生成的
toString是否漏掉了新字段；Lombok 的@ToString默认不包含static或transient字段，需显式配置includeFieldNames = true和doNotUseGetters = true等参数
重写 toString 时字段选哪些？null 怎么处理？
调试用的 toString 不是给用户看的格式化文本，核心诉求是「一眼看出关键状态」。字段选择优先级：标识字段（如 id）、业务主键（如 orderNo）、影响行为的关键状态字段（如 status、isDeleted），而不是堆满所有属性。
- 避免直接拼接可能为
null的引用字段，否则触发NullPointerException—— 推荐用Objects.toString(field, "null")或 Apache Commons Lang 的StringUtils.defaultString(str) - 敏感字段（如
password、token）必须排除，哪怕只是调试；IDE 自动生成时注意取消勾选 - 集合类字段别直接
list.toString()，容易因循环引用或大集合卡住线程；改用list.size()或截取前 3 个元素（list.subList(0, Math.min(3, list.size()))）
日志中 toString 触发了意外副作用
有些开发者会在 toString 里调用 getter、计算逻辑甚至远程调用，结果发现日志一打，接口就变慢或报错。这是因为 toString 在调试、序列化、断点悬停、JMX 检查等场景下会被隐式调用，完全不可控。
-
toString必须是纯函数：无 IO、无锁、不修改状态、不抛受检异常 - 禁止在其中调用可能懒加载的 JPA 关系字段（如
user.getOrders()），会触发 N+1 查询或LazyInitializationException - 如果真需要动态计算字段，应单独提供
toDebugString()方法，并在日志中显式调用，而非依赖自动触发
Spring Boot / Lombok 下 toString 的陷阱
Lombok 的 @ToString 很方便，但默认行为和 Spring 的调试支持有冲突点。比如启用 spring-boot-devtools 后，热重载可能让 toString 缓存失效或生成逻辑错乱；而 @Data 自动包含 @ToString，容易忽略继承链上的字段覆盖问题。
立即学习“Java免费学习笔记（深入）”；
- 使用
@ToString(exclude = {"password", "credentials"})显式排除敏感或高开销字段 - 若类继承自框架基类（如 Spring Security 的
AbstractAuthenticationToken），需加callSuper = true，否则父类字段不参与输出 - 在
application.properties中开启logging.level.org.springframework=DEBUG时，某些 Spring 内部类会频繁调用toString，务必确保你的实现足够轻量
真正难的不是写对 toString，而是预判它在哪种调试路径下会被谁、以什么频率、带着什么上下文调用 —— 这个意识比语法更重要。
