hashmap允许null作为key和value，这是设计选择而非bug；但get()返回null时存在二义性：既可能键不存在，也可能键存在而值为null，易引发逻辑误判和偶发异常。
HashMap 允许 null 作为 key 或 value，这本身不是 bug，而是设计选择；但正因为“允许”，反而容易掩盖逻辑漏洞，造成看似空指针、实则语义模糊的隐患——比如 get(key) 返回 null，你无法立刻判断是“键不存在”，还是“键存在但值就是 null”。这类问题在业务链路中层层传递后，极易演变为难以复现的偶发性异常。
为什么 null 键/值会让判断变得模糊
HashMap 的 get() 方法只返回值，不反馈“是否存在”的元信息。当它返回 null 时，可能对应两种完全不同的场景：
- key 根本不在 map 中（查无此键）
- key 存在，且显式地被 put 过
put(key, null)
这种二义性在 if 判断、DTO 转换、RPC 响应组装等环节特别危险。例如：
// 伪代码：用户信息缓存未命中时返回 null，但业务方误以为是“用户被删”String name = userCache.get(userId);<br>if (name == null) {<br> log.warn("用户 {} 不存在", userId); // 实际上 userId 对应的 name 就是 null<br> throw new UserNotFoundException();<br>}
排查技巧：用 containsKey() + get() 组合代替单次 get
要真正区分“键不存在”和“键存在但值为 null”，必须拆成两步操作：
- 先调用
containsKey(key)确认键是否存在 - 再调用
get(key)获取值（此时可安全断言该 key 存在）
注意：这个组合在多线程环境下仍不安全（A 线程 check 后 B 线程 remove，A 再 get 就得 null），所以仅适用于单线程或已加锁的临界区。高并发场景应改用 ConcurrentHashMap 并规避 null，或封装原子方法如 computeIfPresent。
更稳妥的替代方案：用 Optional 包装返回值
不改变 HashMap 本身，但对外暴露接口时主动消除歧义：
- 定义工具方法：
Optional<v> safeGet(Map<k> map, K key)</k></v>，内部先containsKey再get，有 key 才 wrap，否则 empty - DTO 层统一做非空校验，对可能为 null 的字段明确标注
@Nullable，并约定“null 表示字段未提供”，而非“查无此键” - 数据库映射层避免把 DB 字段的 NULL 直接塞进 HashMap 的 value，优先转成空字符串、默认对象或 Optional 容器
警惕 null key 带来的隐性陷阱
虽然 put(null, "value") 合法，但 null key 会固定落在哈希桶索引 0 的位置，且只能存一个。一旦业务逻辑依赖“遍历所有 key 做处理”，就可能漏掉这个特殊项；更严重的是，某些序列化框架（如 FastJSON 默认配置）会直接跳过 null key，导致数据丢失。
- 除非明确需要（如全局默认配置兜底），否则应禁止使用 null 作为 key
- 可在 put 前加断言：
Objects.requireNonNull(key, "map key must not be null") - 单元测试中专门覆盖
map.containsKey(null)和map.get(null)场景，验证行为是否符合预期
