for range 遍历字符串返回 rune 是因 go 字符串底层为 utf-8 编码，range 语义上遍历 unicode 码点，自动解码 utf-8 并返回 rune（int32）及字节起始位置。
Go 字符串遍历为什么 for range 返回的是 rune 而不是 byte
因为 Go 的字符串底层是 UTF-8 编码的字节序列，但 for range 语义上遍历的是“Unicode 码点”（即逻辑字符），不是字节。它自动解码 UTF-8，每次迭代返回一个 rune（int32 类型）和当前码点在原始字节中的起始位置。
常见错误现象：for i := 0; i 遍历字符串时，遇到中文或 emoji 会切开 UTF-8 字节，导致 <code>s[i] 返回乱码或非法字节；而 for _, r := range s 总是拿到完整字符。
-
len(s)返回字节数，不是字符数；utf8.RuneCountInString(s)才是字符数 - ASCII 字符（如
'a'、'0'）的rune和byte值相同，但类型不同，不能直接混用 - 把
rune强转成byte（比如byte(r)）只取低 8 位，对中文/emoji 会丢数据
什么时候该用 []byte，什么时候该用 []rune
本质区别：前者是原始字节切片，后者是解码后的码点切片。选错会导致截断、乱码或性能浪费。
- 需要按字节操作（如网络协议头、base64 编码、文件二进制读写）→ 用
[]byte - 需要按字符操作（如取第 3 个汉字、反转字符串、统计字符数）→ 先转
[]rune，再索引：rs := []rune(s); rs[2] -
[]rune(s)是 O(n) 拷贝 + 解码，大字符串慎用；若只需遍历，优先用for range，避免额外分配 - 从
[]rune转回字符串是安全的：string(rs)；但从[]byte直接转字符串不校验 UTF-8，可能产生
string 转 []byte 和 []rune 的性能与兼容性差异
两者成本完全不同：[]byte(s) 是零拷贝（底层共享内存），[]rune(s) 必须逐字节解码并分配新切片。
立即学习“go语言免费学习笔记（深入）”；
- 小字符串（[]rune 转换会明显卡顿
- 如果只是检查某个位置是否为字母，用
unicode.IsLetter(rune(s[i]))是错的——s[i]是字节，不是 rune；正确做法是for i, r := range s { if i == targetPos { ... } } - JSON 库（如
encoding/json）内部处理字符串时严格按 UTF-8 字节流，不会自动转rune；自定义 marshaler 里误用[]rune可能拖慢序列化
容易被忽略的边界：BMP 外字符（如 ?）和组合字符（如 é）
一个 emoji 或带重音的字母，在 UTF-8 中可能占多个字节，甚至对应多个 Unicode 码点（如 e\u0301 是 e + 组合尖音符），但 for range 仍每次返回一个 rune —— 这是 UTF-8 解码层保证的，不是 Go 特有逻辑。
-
"??"（程序员 emoji）是多个码点通过 ZWJ 连接的，for range会拆成多个rune，不是单个字符 -
strings.Count(s, "a")统计字节子串；要统计 Unicode 字符，得用utf8.RuneCountInString(s)或手动遍历 - 正则匹配（
regexp）默认按字节工作，想按字符匹配需用\p{L}等 Unicode 类，且注意FindString返回仍是string，不是rune
真正麻烦的从来不是“怎么转”，而是没意识到字符串在 Go 里天然是 UTF-8 字节流，而人眼看到的“字符”是解码后的抽象——这个 gap 一不留神就在索引、切片、正则、网络传输里漏出 bug。
