hashmap允许一个null键是设计使然，通过if(key==null)分支直接存到table[0]避免npe；因==判定所有null键相等，故仅允许一个；而null值不受限。
HashMap的null键是设计使然，不是bug
Java的HashMap明确允许一个null键，这是JDK源码里写死的行为，不是疏漏。它的put和get方法对null做了特殊处理：当键为null时，不走常规哈希计算，而是直接存到数组索引0的位置（即table[0]）。这避免了null.hashCode()抛NullPointerException。
关键点在于：HashMap内部用if (key == null)分支单独处理，而不是依赖hashCode()或equals()——所以即使null没有哈希值，也能安全插入和查找。
为什么只允许一个null键，但允许多个null值
因为HashMap的键必须唯一，而null键的“相等性”由==判定：所有null键都视为同一个键。所以第二次put(null, value)会覆盖第一次的value，不会新增Entry。
-
put(null, "a")→ 插入成功 -
put(null, "b")→ 不新增节点，只更新value为"b" -
put("k", null)→ 完全合法，value可以是任意null对象
换句话说：键的唯一性约束作用于null本身，而value只是普通引用，不受限制。
立即学习“Java免费学习笔记（深入）”；
与HashTable、ConcurrentHashMap对比时要注意空指针风险
HashTable和ConcurrentHashMap完全禁止null键和null值，调用put(null, v)会立即抛NullPointerException。这不是性能考虑，而是线程安全实现的需要——它们无法像HashMap那样在单线程下用简单分支兜底。
常见踩坑场景：
- 把
HashMap换成ConcurrentHashMap做并发改造时，没检查原有null键逻辑，运行时报错 - 工具类接收
Map参数，假设能接受null键，结果传入HashTable实例导致崩溃 -
Objects.requireNonNull(map.get(key))在HashMap中可能误判：返回null未必代表键不存在，也可能是value被显式设为null
实际编码中如何安全使用null键
除非业务逻辑明确依赖“存在一个默认配置项”，否则尽量避免用null作键。它会让代码可读性和可维护性下降，尤其在debug时难以区分“没找到”和“找到了但值为空”。如果真要用，务必配合注释和防御性判断：
map.put(null, defaultConfig); // 表示全局默认配置
// 后续获取时不能只靠 == null 判断是否存在
if (map.containsKey(null)) {
Config cfg = map.get(null);
}
更稳妥的做法是用一个专用哨兵对象，比如private static final Object DEFAULT_KEY = new Object();——这样既保持语义清晰，又避开null带来的歧义和兼容性问题。
