range遍历切片时修改元素值不生效，因默认拷贝值而非引用；需通过索引赋值如s[i] = newValue；遍历map顺序随机，非bug，需排序key再遍历；channel上range会阻塞至关闭。
range遍历切片时为什么修改元素值不生效
因为 range 默认拷贝元素值，不是引用。对循环变量赋值只改了副本，原切片不变。
- 要修改原切片元素，必须用索引：
for i := range s { s[i] = newValue } - 如果需要同时读取值和修改，写成
for i, v := range s { s[i] = v * 2 }，注意别误用v做赋值目标 - 结构体切片尤其容易踩坑——即使
v是结构体，v.field = x也不会影响原切片，除非字段是指针或切片本身
range遍历 map 时的顺序与一致性问题
Go 的 range 遍历 map 是随机起始、伪随机顺序，每次运行都可能不同。这不是 bug，而是为防依赖顺序的代码被默许。
- 不要假设
range m每次输出键的顺序一致；测试中偶然固定不代表生产稳定 - 如需确定顺序（比如调试输出、序列化），先收集 key 到切片，排序后再遍历：
keys := make([]string, 0, len(m)); for k := range m { keys = append(keys, k) }; sort.Strings(keys); for _, k := range keys { ... } - 并发读写 map 时，
range可能 panic 报fatal error: concurrent map iteration and map write，必须加锁或用sync.Map
range 在 channel 上阻塞与退出逻辑
range 作用于 channel 时，会持续接收直到 channel 被关闭；一旦关闭，循环自动退出。但若 channel 永不关闭，range 就永远阻塞。
- 务必确保发送方在所有数据发完后调用
close(ch)，否则接收方卡死 - 不能在多 goroutine 中重复
close(ch)，会 panic：panic: close of closed channel - 如果只是想“尝试接收一次”，别用
range，改用select+case v, ok := 判断是否就绪或已关闭 - 注意：向已关闭的 channel 发送数据会 panic，接收则立即返回零值 +
ok == false
range 性能陷阱：字符串遍历时的 rune vs byte
Go 字符串底层是字节序列，range 字符串时按 rune（Unicode 码点）迭代，不是按字节。这意味着每次迭代都要做 UTF-8 解码，有额外开销。
立即学习“go语言免费学习笔记（深入）”；
- 如果明确处理 ASCII 或只需字节操作（如查找某个 ASCII 字符），用
for i := 0; i 更快 -
range s返回的是index, rune，不是byte；索引是字节偏移，不是 rune 序号（中文等多字节字符会导致索引跳跃） - 想统计字符数？用
utf8.RuneCountInString(s)，别靠range计数器——它数的是 rune 个数，但索引跳变会让新手误以为是“位置”
实际写多了就会发现，range 表面简单，但每个类型背后的行为差异和隐含约束，往往在上线后才暴露。尤其是 map 遍历顺序、channel 关闭时机、字符串索引语义这三处，最容易被当成“理所当然”而埋下非预期行为。
