遍历切片用range快，遍历map慢十几倍，因slice内存连续、cpu缓存友好，而map需遍历全部桶数组（含空桶）并处理哈希冲突；slice遍历o(n)且常数小，map遍历o(n+b)，b为桶数且顺序不固定。
遍历切片用 range 是快的，遍历 map 用 range 是慢的——这不是写法问题，是底层结构决定的。
为什么遍历 map 比遍历 slice 慢十几倍
Go 的 slice 在内存中是连续块，range 遍历时只需按地址偏移读取，CPU 缓存友好；而 map 是哈希表实现，range 必须遍历整个底层桶数组（包括空桶），还要处理冲突链、重新散列状态等逻辑。哪怕 map 只有 10 个键值对，range 仍可能扫描数百个桶槽。
实测：5000 万元素的 slice 遍历耗时约 20ms，同等规模 map[int]int 遍历耗时常超 300ms——差距来自访问模式，而非语法本身。
- slice 遍历时间复杂度：O(n)，且常数极小
- map 遍历时间复杂度：O(n + B)，B 是底层桶数量，通常 ≥ n，且受装载因子影响
- map 遍历顺序不固定，每次都要重建迭代器状态，无法像 slice 那样做简单指针递增
range 遍历 slice 时，v 是拷贝还是引用
是拷贝。每次迭代都会把当前元素复制一份到 v 中。对小类型（如 int、string）影响微乎其微；但对大结构体或含指针字段的类型，会带来明显开销。
如果你只读不改，又在意性能，可以改用索引访问：
for i := 0; i
- 用
range s→ 拷贝每个元素值 - 用
for i := range s+s[i]→ 按需取值，无额外拷贝 - 若需地址（比如修改原 slice 元素），必须用索引方式，
range中的v改了也无效
map 遍历时能否跳过空桶或加速
不能。Go 运行时未暴露底层桶结构，range 是唯一安全遍历方式。任何试图绕过它的做法（比如反射读桶数组、unsafe 指针强转）都违反内存模型，且在 GC 或 map 扩容时极易崩溃。
真正有效的优化路径只有两条：
- 如果只是查某个 key，别遍历——直接用
m[k] - 如果必须全量处理，且数据可预知范围，考虑换结构：用
[]struct{key, value int}+ 排序 + 二分，或用map配合维护一个额外的 key 列表（keys := make([]int, 0, len(m))），遍历列表再查 map - 注意：
len(m)是 O(1)，但range m不是，别误以为“长度已知就快”
什么时候该坚持用 range 遍历 map
当语义正确性比性能更重要时。比如配置加载、调试打印、初始化校验等场景——代码清晰、不易出错，几毫秒延迟无关紧要。
但若出现在高频路径（如 HTTP handler 内部、实时计算循环中），尤其 map 规模 > 10k，就要警惕。此时应明确问自己：是否真的需要遍历全部？能否提前 break？有没有更紧凑的数据表示？
最容易被忽略的一点：map 遍历性能和其历史操作强相关。频繁 delete 后未 rehash 的 map，桶数组会严重膨胀，range 耗时可能翻倍——这种退化不会报错，也难被监控发现。
