containsKey方法用于判断Map是否包含指定键，返回true表示键存在、false表示不存在；它只检查键而非值，即使键对应值为null也返回true，且要求Map已初始化、键的equals与hashCode一致。
containsKey 方法的基本用法和返回值含义
containsKey 是 Java 中 Map 接口定义的标准方法，用于判断当前 Map 实例是否包含指定的键。它不关心值是否为 null，只检查键是否存在（即调用 key.equals() 是否有匹配项）。返回 true 表示键存在，false 表示不存在或 Map 为 null（此时会抛出 NullPointerException）。
常见错误是误以为 containsKey 能判断“键存在且对应值非 null”，其实不是——哪怕 map.put("k", null) 后调用 map.containsKey("k") 仍返回 true。
- 必须确保
Map对象已初始化，否则调用containsKey会直接抛出NullPointerException - 键的
equals和hashCode实现必须一致，否则可能在HashMap中查不到本应存在的键 - 对
ConcurrentHashMap调用containsKey是线程安全的，但结果只代表“某一时刻”的快照，不能用于条件竞争场景（如先查再 put）
为什么不能用 get(key) != null 替代 containsKey(key)
用 map.get(key) != null 判断键存在，看似简洁，但有严重逻辑漏洞：当键存在但值恰好为 null 时，该表达式返回 false，误判为“键不存在”。而 containsKey 完全绕过值，只关注键的哈希与 equals。
例如：
Map<string string> map = new HashMap();
map.put("name", null);
System.out.println(map.get("name") != null); // false —— 错！键明明存在
System.out.println(map.containsKey("name")); // true —— 正确</string>
- 若你不确定值是否可能为
null，绝对不要用get != null做存在性判断 - 某些 Map 实现（如
WeakHashMap）中，get还可能触发清理逻辑，带来额外开销或副作用 - 从语义上，
containsKey更清晰地表达了“我只关心键”，提升可读性和意图明确性
在不同 Map 实现中的行为差异和注意事项
containsKey 在所有标准 Map 实现中语义一致，但性能和边界行为略有不同。
-
HashMap/LinkedHashMap：平均时间复杂度 O(1)，依赖键的hashCode分布；若键重写了hashCode但没重写equals，可能导致漏判 -
TreeMap：基于红黑树，时间复杂度 O(log n)，要求键实现Comparable或传入Comparator；若键类型不满足比较约束，运行时抛ClassCastException -
ConcurrentHashMap：支持高并发，但containsKey不是原子性操作——它不阻止其他线程在调用前后修改该键 -
Collections.unmodifiableMap(...)包装后的 Map，containsKey仍可用，但任何修改操作会抛UnsupportedOperationException
实际开发中容易忽略的三个细节
多数人能写出 map.containsKey(x)，但以下三点常被跳过，导致线上问题：
- 传入
null作为参数：部分Map实现（如HashMap）允许null键，但TreeMap不允许，调用containsKey(null)会立即抛NullPointerException或ClassCastException - 使用可变对象作键且修改了其参与
hashCode/equals的字段：修改后containsKey可能返回false，即使该键曾被成功插入 - 在循环中反复调用
containsKey+get：不如直接用get并判空，或用computeIfAbsent等更高效方式，避免两次哈希查找
键存在性判断本身很简单，但真正难的是确保键的语义稳定、Map 实例状态可靠、以及理解「存在」在并发或可变场景下的真实含义。
