应优先使用 find 或 C++17 的 contains 判断 map 键是否存在；count 效率低且无法取值，operator[] 会意外插入默认构造值，引发性能与逻辑问题。
用 count 判断 map 键是否存在？小心性能陷阱
count 确实能返回 0 或 1，看起来很直观，但对 std::map（底层是红黑树）来说，它必须走完整个查找路径才能确认“不存在”，不能提前终止。更关键的是：它只告诉你“有没有”，不给你值的引用或迭代器——意味着你想取值时还得再查一遍。
- 对
std::unordered_map（哈希表），count平均 O(1)，但依然不返回位置，纯属多一次哈希计算 - 如果后续要读/改对应 value，用
count+operator[]会触发两次查找，白耗 CPU - 注意：
count对std::multimap有意义（可能有多个同键），但普通map里永远只有 0 或 1
find 是更直接、更高效的选择
find 返回迭代器，查到了就指向键值对，没查到就等于 end()。一次调用，既能判存在，又能拿值，还能安全修改——没有冗余操作。
- 判断存在：
if (m.find(key) != m.end()) { ... } - 同时取值：
auto it = m.find(key); if (it != m.end()) use(it->second); - 避免
operator[]的副作用：它会在键不存在时默认构造 value，对复杂类型可能引发意外初始化或内存分配 - 对
const map，find是唯一可读且不改变容器的方式；operator[]根本不可用
别用 operator[] 来判断存在性
operator[] 表面简洁，但本质是“访问+插入”操作。哪怕你只写 m[key] 却不赋值，只要 key 不存在，它就会默认构造一个 value 并插入进去——这通常不是你想要的“判断”行为。
- 后果包括：容器 size 意外增长、value 被默认初始化（比如
std::string变成空串、自定义类调用无参构造）、甚至引发异常（如构造函数抛异常） - 仅当明确需要“有则取、无则建并返回引用”时才用
operator[]，比如计数场景：++counter[key]; - 想“只读不写”，又懒得写
find，可以用 C++17 的try_emplace或insert_or_assign配合返回值，但它们也不是存在性检查的替代品
C++17 起有了更省事的写法：contains
std::map 和 std::unordered_map 在 C++17 加入了 contains 成员函数，语义清晰、不修改容器、不构造 value、也不返回迭代器——就是纯粹回答“有没有”。
立即学习“C++免费学习笔记（深入）”；
- 写法最干净：
if (m.contains(key)) { ... } - 内部实现等价于
find(key) != end()，所以性能和find一样好 - 注意兼容性：低于 C++17 的标准库不支持，GCC 7.1+ / Clang 5+ / MSVC 2017 15.3+ 才可用
- 它不提供值访问能力，所以仍需搭配
find或at（后者查不到会抛std::out_of_range）来取数据
operator[]，优先选 find；C++17 起有 contains 就更直白。真正容易被忽略的是——很多人写了 count 后顺手又写一遍 operator[]，结果在循环里把 O(log n) 查了两次。 
