重写 toString() 应按场景权衡性能与可读性：调试期可含全量字段，生产日志限3–5个核心字段，集合打印需轻量；规避耗时操作、递归引用、格式化开销及重复计算；用紧凑格式、统一空值表示、截断长字符串、布尔缩写提升信息密度；不可变对象天然线程安全。
重写 Object.toString() 时，性能和可读性不是非此即彼的选择，而是需要按场景权衡的协作关系。关键不在于“要不要输出所有字段”，而在于“哪些字段对当前用途真正必要”。默认实现（类名@哈希码）完全放弃可读性；全量拼接所有字段又可能拖慢日志或高频调用路径。真正的平衡点藏在目的、数据特征和运行环境里。
明确 toString 的主要用途，再决定内容粒度
同一个类的 toString() 很少能同时完美服务所有场景。建议按优先级区分：
-
调试/开发期：可包含全部业务字段，甚至嵌套对象的简要摘要（如
address=[City:Beijing, zip:100000]），但避免深层递归或 I/O 操作； - 生产日志：只保留核心标识字段（如 ID、状态、关键数值），字段数控制在 3–5 个以内，避免日志体积膨胀和 GC 压力；
-
集合打印（如
System.out.println(list)）：依赖每个元素的toString()，此时更需轻量——建议仅返回唯一标识 + 状态，例如Order{id=ORD-2026-789, status=CONFIRMED}。
规避常见性能陷阱，而非一味删减字段
慢的往往不是字符串拼接本身，而是拼接过程中触发的副作用：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
避免在 toString 中调用耗时方法：比如
getFile().length()、getJsonString()、数据库查询等；应提前缓存或跳过； -
警惕递归引用：若 A 包含 B，B 又持有 A 的引用，直接拼接会栈溢出。可用 ThreadLocal 记录已访问对象 ID，遇到重复引用时显示
[CircularRef]； -
慎用格式化工具：
String.format()或MessageFormat比字符串拼接开销大；简单场景用"key=" + value更高效； - 避免重复计算：如某字段是通过复杂逻辑算出的，且不常变，可考虑懒加载并缓存其字符串表示。
用结构化方式提升信息密度，减少冗余字符
精简不是删字段，而是让每个字符承载更多有效信息：
立即学习“Java免费学习笔记（深入）”；
- 用紧凑格式代替自然语言：用
Person{name=Tom,age=32}而非姓名: Tom, 年龄: 32； - 对 null 或空值做统一简写：用
name=null或tags=[]，不写name is null； - 长字符串截断处理：如
desc=“这是一段超长描述...[truncated]”，避免日志被撑爆； - 布尔值用缩写：用
active=true而非isActive=true，前提是字段名已表明语义。
线程安全与不可变性的隐性收益
如果类本身是不可变的（如 record 或 final 字段+无 setter），toString() 天然线程安全，无需同步，也无需担心字段中途变更导致输出不一致。这对高频日志场景尤其重要。反之，若对象可变且多线程访问，应避免在 toString() 中读取未同步的字段，或使用 volatile 保证可见性——但更推荐设计上减少这种需求。
