答案是：需确保两个key的hashcode相同但equals返回false，否则put会替换而非挂链表；调试时在p.next = newnode(...)处设断点，逐层展开variables中tab[i]的next字段观察链表结构。
用断点+内存视图看 HashMap 的 Node 链表挂载
Java 8+ 的 HashMap 在哈希冲突时，先用链表（Node）存储，链表长度 ≥ 8 且桶数组长度 ≥ 64 才转红黑树。想亲眼看到节点怎么“挂”上去，不能只靠日志打印——得进调试器里盯住 table 数组和每个 Node 的 next 字段。
关键动作：在 putVal 方法的链表遍历和插入分支设断点，配合「Variables」面板展开 tab[i]，观察 next 指针如何串起新节点。
- 用 JDK 8u292 或更新版本（避免早期 8u 版本中
Node字段名不一致问题） - 确保 VM options 加上
-XX:-UseCompressedOops（可选，避免 64 位 JVM 下对象地址被压缩导致指针难追踪） - 写一个最小复现：构造两个不同对象但
hashCode()相同、equals()返回false，连续put进去
为什么 put 两次相同 hash 却没触发链表？
常见现象：断点停在 putVal，发现第二次 put 直接替换旧值，没走链表逻辑——说明两个 key 被判定为「逻辑相等」，不是碰撞，是覆盖。
根本原因在 putVal 的这个判断：p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k)))。只要 equals 返回 true，就不会新建 Node，更不会挂链表。
- 验证方式：在调试时展开第一个
Node，看key.equals(新key)是否为true - 正确构造碰撞：重写
hashCode固定返回1，但equals只对自身实例返回true（比如用this == obj） - 别用
String或Integer做测试 key——它们的equals太“智能”，容易误判为重复
调试时怎么看 next 指针连成链表？
当成功触发链表挂载后，在调试器 Variables 面板里展开 tab[i]（即发生碰撞的桶），你会看到一个 Node 实例；再展开它的 next 字段，指向下一个 Node；继续展开，直到 next == null ——这就是当前链表的完整结构。
- 注意：IDE（如 IntelliJ）默认只展开一层引用，需手动点击
next左侧的小箭头逐层展开 -
Node的字段顺序是：hash、key、value、next；重点盯next是否非空 - 如果用了 JFR 或 Async-Profiler，会干扰对象内存布局，建议关闭所有 profiler 再调试
从源码行号定位链表插入的关键位置
OpenJDK 8 的 HashMap.putVal 中，链表插入实际发生在循环末尾的 if ((e = p.next) == null) 分支内：p.next = newNode(hash, key, value, null)。这一行就是「挂载」发生的精确位置。
- 在该行打条件断点，比如
e == null && p != null，能精准捕获每次新节点挂到链尾的瞬间 - 不要在
for循环头部设断点——那里只是查找，还没到挂载 - 如果用的是 Java 17+，注意
Node类已移到HashMap.Node内部，但字段名和逻辑完全一致
链表是否形成，不取决于你放了多少个 key，而取决于「hash 相同 + equals 不等」的组合是否真实发生；很多调试失败，其实卡在了 key 的语义设计上，而不是工具不会用。
