最推荐用 for (const auto& p : map) 遍历，简洁安全、避免拷贝；需修改 value 时用 begin()/end()；依赖顺序选 std::map；unordered_map 遍历顺序不可靠，切勿依赖。
用 for (const auto& p : map) 最省心
这是 C++11 起最推荐的写法，语法简洁、语义清晰、性能不打折。编译器能自动推导 std::pair<const key value></const> 类型，避免拷贝（const auto& 是关键），也不用写迭代器类型。
常见错误是写成 for (auto p : map) —— 这会触发每次遍历都拷贝整个 std::pair，尤其当 Value 是大对象（如 std::string、std::vector）时开销明显。
- 适用场景：只读遍历，不需要修改键值对
- 注意
map是有序的，遍历顺序就是 key 的升序（std::map）或哈希顺序（std::unordered_map） - 如果需要解构 key 和 value，可直接写
for (const auto& [k, v] : map)（C++17 结构化绑定）
std::map::iterator 遍历时别漏掉 const
显式使用迭代器适合需要中途修改 value 或控制遍历逻辑（比如跳过某些项、提前退出）的场景。但新手常犯的错是声明非 const 迭代器却只读访问，或者反过来——用 const_iterator 却试图改 ->second。
真实错误现象：error: assignment of member 'second' in read-only object，往往是因为用了 map.cbegin() 却想赋值；或者用 map.begin() 但容器本身是 const 引用，导致编译失败。
立即学习“C++免费学习笔记（深入）”；
- 只读遍历 → 优先用
cbegin()/cend()，安全且意图明确 - 要改 value → 用
begin()/end()，但不能改->first（key 不可变） - 不要手写
std::map<int std::string>::iterator</int>—— 类型太长，也容易和unordered_map混淆，一律用auto
std::for_each + lambda 容易踩内存生命周期坑
这招适合把遍历逻辑抽成独立函数或复用已有处理逻辑，但要注意 lambda 捕获方式。最典型问题是用 [&] 捕获外部变量，而该变量在 lambda 执行前已析构（比如传给异步任务或缓存了 lambda 对象）。
另一个隐形坑是：lambda 中取 it->second 地址后，map 发生 rehash（unordered_map 插入/删除较多时）或节点重排（map 平衡调整），指针/引用立刻失效。
- 只读操作 → 用
[&map](const auto& p) { ... }显式按需捕获，避免意外捕获无关变量 - 别在 lambda 里保存
&p.second或p.second.data()这类裸指针，除非你 100% 确保 map 生命周期更长 - 性能上无优势，反而有函数调用开销，纯遍历没必要硬套
三种方式性能其实没差别，但 unordered_map 的遍历顺序不可靠
底层都是 O(n) 时间复杂度，现代编译器对三者优化程度接近。真正影响实测速度的是 cache 局部性：std::map 节点分散在堆上，遍历慢；unordered_map 桶数组连续但存在空洞，也不理想；只有 std::vector<:pair></:pair> 手动排序后遍历才最友好。
最容易被忽略的一点：很多人以为 unordered_map “遍历顺序随机”只是理论提醒，实际测试好像每次都一样。但这是实现细节（比如桶大小、哈希种子），一旦升级标准库、换编译器、甚至加个调试宏，顺序就可能突变。依赖遍历顺序的代码在生产环境大概率出问题。
- 如果业务逻辑依赖“先插入的先遍历”，别用
unordered_map，换std::map或自己维护std::vector+std::unordered_map双结构 - debug 时打印
unordered_map内容，别凭眼见判断顺序是否“稳定” - 没有银弹——选哪种方式，取决于你要不要改值、要不要中断遍历、以及是否在意顺序语义
