应优先使用 find 判断 key 是否存在，因其一次调用即可完成存在性判断与值访问，避免重复查找、兼容 const 场景且无语言标准限制；count 效率低且易引发二次查找，contains 虽语义清晰但需 C++20 支持。
用 count 判断 key 是否存在，简单但有代价
直接调用 map::count(key) 能返回 1 或 0，看起来最直白。但它底层必须完成一次完整查找（红黑树遍历），哪怕你只关心“有没有”，它也得走到叶子节点确认唯一性。对 std::map 来说，这和 find 时间复杂度一样是 O(log n)，但语义上多了一层“计数”含义，实际并不需要计数——std::map 的 key 天然不重复，count 永远只会返回 0 或 1。
常见误用场景：在循环里反复写 if (m.count(k)) { auto v = m[k]; ... }，这会触发两次查找（count 一次，operator[] 又一次），还可能意外插入默认构造的 value。
- 别用
count+operator[]组合查值，性能差且危险 - 如果真只需要布尔判断（比如日志开关、配置跳过），
count可读性尚可，但不是最优解 -
unordered_map同样适用，但哈希冲突多时count的常数开销更明显
用 find 查找并复用迭代器，才是标准做法
find 返回 iterator，查到了就指向该键值对，没查到就等于 end()。关键在于：一次调用，既能判断存在性，又能直接取值，零额外开销。
典型错误写法：if (m.find(k) != m.end()) { auto v = m[k]; } —— 这又触发了第二次查找。
立即学习“C++免费学习笔记（深入）”；
- 正确姿势是先存迭代器：
auto it = m.find(k); if (it != m.end()) { use it->second; } - 如果后续还要修改 value，直接用
it->second = new_val;，避免再次定位 - C++17 可用结构化绑定简化：
if (auto it = m.find(k); it != m.end()) { auto& [key, val] = *it; ... }
contains（C++20）让判断更干净，但要注意兼容性
C++20 引入了 map::contains(key)，纯布尔返回，语义清晰，且不改变容器（不触发插入，不返回迭代器）。它内部通常就是封装了 find != end()，所以性能和 find 一致。
问题在于：老项目或交叉编译环境（如某些嵌入式工具链、macOS 默认 clang 版本）可能不支持 C++20。盲目启用会报错 error: no member named 'contains' in 'std::map<...>'</...>。
- 确认编译器支持：gcc >= 10、clang >= 10、MSVC >= 19.20
- 编译需显式加
-std=c++20（或c++2a），部分 IDE 默认仍是 c++17 - 若需兼容旧标准，别为了语法糖强行升级，老老实实用
find
别忽略 const 场景下的 find 和 at
在 const 成员函数里，或面对 const map 引用时，operator[] 不可用（它可能插入），at 会抛异常，而 find 仍可安全使用——只要调用的是 const 版本 const_iterator find(...) const。
有人想用 at 替代 find 判断存在性，但 at 在 key 不存在时抛 std::out_of_range，用异常控制流程既低效又违背直觉，属于典型反模式。
- const 上下文首选
find，配合!= end()判断 -
at只适用于“我 100% 确定 key 存在，否则程序本就不该继续”的强契约场景 - 捕获
at异常来兜底，相当于用异常代替条件分支，运行时成本高得多
find 是最平衡的选择：无兼容性风险、一次调用完成判断+取值、const 安全、语义明确。那些为少写几个字符而选 count 或硬上 contains 的地方，往往藏着多一次查找或编译失败的隐患。 
