优先用 range 遍历 slice，因 Go 编译器对其做了边界检查消除等优化，比传统 for 循环更高效；遍历开销小，性能瓶颈多源于循环体内重复计算、内存分配等操作。
在 Go 中遍历 slice 和 map 本身开销不大，真正影响效率的是遍历过程中的操作——比如重复计算、非必要内存分配、类型转换或错误的迭代方式。优化关键在于减少冗余、利用语言特性、避免隐式开销。
优先用 range 遍历 slice，避免下标越界检查冗余
Go 编译器对 for range 遍历 slice 做了专门优化（如消除边界检查），比传统 for i := 0; i 更高效，尤其在循环体简单时：
- ✅ 推荐：
for i, v := range s { ... }—— 编译器可内联、省去每次i 检查 - ❌ 避免：
for i := 0; i —— 每次都查长度，且若 <code>s是函数返回值，len()可能被多次调用（虽小但累积） - ? 小技巧：如果只用索引不用值，写
for i := range s，比for i := 0; i 更简洁且性能一致
遍历 map 时按需选择：range vs keys + for
for k, v := range m 是最常用也通常最优的方式，但要注意两点：
- ✅ 无序性是设计使然，不需额外排序就直接消费键值对时，
range最快 - ⚠️ 若需按 key 排序遍历（如打印、调试），先取
keys := make([]KeyType, 0, len(m))，再for k := range m { keys = append(keys, k) }，排序后遍历 —— 避免边遍历边排序或反复查 map - ❌ 不要为了“提前退出”而改用
for _, k := range keys { v := m[k]; ... }且 keys 未预分配容量，这会引发多次扩容
避免在循环中做重复工作
常见低效模式集中在循环体内重复调用函数、创建对象或做类型断言：
Node.js 可靠编程
下载
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
立即学习“go语言免费学习笔记（深入）”；
- ❌ 错误示例：
for _, item := range list { json.Marshal(item); ... }—— 每次都新建 bytes.Buffer，触发 GC 压力 - ✅ 改进：复用
bytes.Buffer或预分配切片；若只是判断结构体字段，直接访问字段而非序列化后再解析 - ❌
for k, v := range m { str := fmt.Sprintf("%s:%v", k, v); ... }—— 字符串拼接频繁分配内存 - ✅ 改进：用
strings.Builder或fmt.Fprintf(&builder, "%s:%v", k, v)
注意 slice 和 map 的底层行为差异
理解底层机制能帮你避开“看似合理实则慢”的写法：
- ? slice 遍历本质是连续内存读取，CPU 缓存友好；map 遍历是哈希桶+链表跳转，缓存不友好，天然比 slice 慢 2–5 倍（取决于数据量和分布）
- ? map 遍历顺序不固定，且每次
range都从随机桶开始 —— 这不是 bug，是为防止程序依赖遍历顺序而做的安全设计 - ? 如果业务允许，考虑是否能用 slice 替代 map（例如 ID 连续、范围可控时用
[]*T索引）；或者用sync.Map仅在并发读多写少场景下替代原生 map
基本上就这些。不复杂，但容易忽略细节。核心就一条：让编译器帮你省事，别替它做重复劳动。
