Go中range遍历字符串实际按rune（Unicode码点）而非byte进行，i为字节偏移、r为rune值；len(s)返回字节数，字符数需用utf8.RuneCountInString(s)。
range 字符串实际遍历的是 rune，不是 byte
Go 的 range 对字符串做迭代时，底层会按 UTF-8 编码解码，每次返回一个 rune（即 Unicode 码点）和对应起始字节索引，而不是逐字节取 byte。这意味着 for i, r := range "你好" 中的 i 是字节偏移（0、3、6），r 是 rune 值（'你'、'好'），不是 uint8。
常见错误现象：
– 用 string[i] 按索引取字符时 panic 或拿到乱码（比如 "你好"[1] 得到 0xe4，不是有效字符）
– 误以为 len("你好") == 2，实际是 6（UTF-8 字节数）
- 需要字符个数用
utf8.RuneCountInString(s)，不是len(s) - 要按字节操作（如网络协议解析）就别用
range，改用[]byte(s)+ 普通 for - 想同时拿到字符和位置？
range给的i是字节偏移，不是字符序号；需自己计数或用strings.IndexRune辅助
for range s 返回的 index 是字节位置，不是 rune 序号
这是最容易踩的坑：遍历 "a你" 时，range 返回的 i 是 0（'a' 起始）、1（'你' 起始字节，即 0xe4 所在位置），不是 0、1 表示第几个字符。如果你写 s[i:i+1] 想截单个“字符”，对多字节 rune 就会出错。
使用场景举例：日志里按字符位置高亮报错位置，但直接用 range 的 i 当“列号”会导致偏移错乱。
- 需要真正的字符序号（第几个 rune）？自己维护计数器：
for i, r := range s { pos++ } - 想从字符串中安全切出第 n 个 rune？用
utf8.DecodeRuneInString循环解码，或转成[]rune(s)[n]（注意内存分配） -
strings.IndexRune(s, '你')返回的是字节偏移，和range的i对齐，可直接用于切片
[]rune(s) 和 range s 都能拿到 rune，但开销和用途不同
两者都解决“按字符而非字节遍历”的问题，但机制完全不同：range s 是边解码边迭代，O(n) 时间、O(1) 额外空间；[]rune(s) 是一次性把整个字符串解码进新切片，O(n) 时间、O(n) 空间。
立即学习“go语言免费学习笔记（深入）”；
性能影响明显：处理 MB 级日志字符串时，[]rune(s) 可能触发 GC 压力，而 range 几乎无额外分配。
- 只读遍历、不需要随机访问？无条件选
range s - 要反复按索引查某个位置的 rune（如语法分析器跳转）？
[]rune(s)更快，但确认字符串不会太大 - 注意：
[]rune(s)[0]是第一个 rune，但len([]rune(s))才是字符数；len(s)仍是字节数
fmt.Printf("%c") 和 "%q" 对 rune 的输出行为差异
调试时容易混淆：用 fmt.Printf("%c", r) 输出 rune 会显示字符本体（如 '你'），但 fmt.Printf("%q", r) 显示带单引号的转义形式（如 '\u4f60'），而 fmt.Printf("%d", r) 显示 Unicode 码点数值。
错误现象：打印 range 出来的 r 时用了 %s，结果 panic（%s 要 string，不是 rune）；或者用 %x 看到一串字节，误以为是 rune 本身。
- 安全打印单个 rune：用
%c（字符）、%U（U+4F60 格式）、%d（十进制码点） - 想看它在原字符串里的字节表现？用
string(r)转成字符串再%x，例如fmt.Printf("%x", string('你'))→e4bda0 - 别对
rune用%s，也别对string用%c，类型错配会编译失败或运行时 panic
真正麻烦的是混合场景：比如解析 HTTP header 里的中文参数，既要按字节找分隔符（;、=），又要正确提取 value 中的中文字符——这时候得明确区分哪段该当字节流处理，哪段该当 rune 流处理，不能靠一个 range 全包圆。
