Map.toString() 输出哈希值因键值类型未重写toString()；调试推荐IDE变量展开或Jackson转JSON，重写toString()需防递归、副作用和null异常。
Map.toString() 为什么总输出哈希值
因为 HashMap、LinkedHashMap 等默认继承自 AbstractMap，其 toString() 是用 entrySet() 遍历拼接的，但键值类型若没重写 toString()（比如自定义对象），就会显示 com.example.User@1a2b3c 这种，根本看不出内容。
常见错误现象：System.out.println(map) 输出一长串带 @ 符号的字符串，调试时完全没法快速定位数据是否正确。
- 如果只是临时调试，别改类，用
forEach+ Lambda 更轻量 - 如果该 Map 的 value 是统一的业务对象（如
User），建议在User类里重写toString()，而不是在每次打印时处理 - 注意
toString()重写后会影响日志、断点变量查看、JSON 序列化前的 toString 调试等所有场景，不是仅限于控制台打印
用 forEach + Lambda 一行打印 Map 的实际写法
比手写 for-each 循环简洁，又比 toString() 可控——能格式化缩进、过滤空值、转换字段名。关键在于别直接在 Lambda 里写复杂逻辑，否则可读性反降。
示例：打印 Map<string integer></string>，只输出 value > 10 的项：
立即学习“Java免费学习笔记（深入）”；
map.entrySet().forEach(entry -> {
if (entry.getValue() > 10) {
System.out.println(entry.getKey() + " => " + entry.getValue());
}
});
- 不要在 Lambda 中调用耗时操作（如 DB 查询、IO），
forEach是同步阻塞的 -
entrySet()比keySet()+get()更高效，避免重复哈希查找 - 如果需要按插入顺序打印，确保用的是
LinkedHashMap；TreeMap会按 key 排序，不是原顺序
重写 toString() 的安全边界在哪
重写 toString() 确实一劳永逸，但必须守住三条线：不抛异常、不触发副作用、不递归引用自身。
典型翻车场景：User 类里有 Department dept 字段，而 Department 又引用回 User 列表 —— 重写时若不加限制，toString() 会无限递归，最终 StackOverflowError。
- 用
Objects.toString(obj, "null")替代直接调用obj.toString()，自动处理 null 安全 - 对可能循环引用的字段，只打印 ID 或 class 名，例如
"dept=" + Objects.toString(dept.id, "null") - 避免在
toString()里调用 getter 方法，尤其当 getter 带计算或懒加载逻辑时（比如getFullName()拼接了数据库字段）
调试时真正好用的替代方案
与其纠结怎么“优雅”打印，不如用更贴近调试本质的方式：结构化、可复制、免解析。
推荐组合：System.out.println(new ObjectMapper().writeValueAsString(map))（需 Jackson）或用 IDE 的「Evaluate Expression」直接展开 map 变量——它会渲染成树形，支持点击展开嵌套结构，比任何 toString() 都直观。
- JSON 方式适合 Map 值是 POJO 或基础类型；含
java.time.*或自定义序列化器时要配好ObjectMapper - IDE 调试视图不依赖代码修改，且能实时看到当前快照，但无法用于日志留存
- 线上环境禁用 JSON 打印大 Map，容易 OOM 或拖慢响应；调试阶段才用
最常被忽略的一点：Map 可能包含 null key 或 null value，toString() 和 forEach 都不会报错，但 JSON 序列化默认拒绝 null value（除非配置 setSerializationInclusion(JsonInclude.Include.NON_NULL)）——这种隐性差异，上线前不测就容易出问题。
