for range遍历字符串时i是字节偏移量而非字符序号；需字符序号应手动计数；取第N字符须转[]rune；len([]rune(s))不适用emoji等组合字符；优先用utf8.RuneCountInString统计长度；源头编码不明时需先转换再遍历。
for range 遍历字符串时，i 是字节偏移量，不是字符序号
很多人写 for i, r := range s 后误以为 i 是“第几个字符”，结果发现中文或 emoji 的 i 跳变（比如 “世” 占 3 字节，i 从 0 跳到 3）。这没问题——i 就是 UTF-8 编码中该 rune 的起始字节位置，不是逻辑序号。
需要字符序号？自己维护计数器：
idx := 0<br>for _, r := range s {<br> fmt.Printf("第 %d 个字符: %c\n", idx, r)<br> idx++<br>}
- 直接用
len([]rune(s))得到总字符数，但别在循环里反复调用——每次转换都新建底层数组 - 如果只关心 rune 值（比如过滤标点），用
for _, r := range s更简洁，省掉无用的i - 用
unicode.IsLetter(r)或unicode.IsDigit(r)判断时，r是 int32，可直接传入，无需转类型
想通过下标取第 N 个中文字符？先转 []rune，但别滥用
string 不支持 s[2] 取第三个汉字——那只是第三个字节，大概率是乱码。必须显式转成 []rune：
chars := []rune(s)<br>if len(chars) > 2 {<br> third := chars[2]<br>}
立即学习“go语言免费学习笔记（深入）”；
- 转换开销真实：对 1MB 字符串，
[]rune(s)会分配约 1MB 内存（每个 rune 占 4 字节）+ 一次 UTF-8 解码 - 别写
[]rune(s)[n]这种临时转换——每次执行都新建 slice，GC 压力陡增 - 若只需取前几个字符（如截断显示），用
strings.Builder+for range累加更省内存
emoji 和组合字符会让 len([]rune(s)) 失效
一个笑脸 ? 在 UTF-8 中占 4 字节，[]rune("?") 长度是 2；带声调的 “á” 可能是 'a' + '\u0301'，长度也是 2。这些都不是单个“视觉字符”。
所以：
- 统计“人眼看到的字形数”不能靠 len([]rune(s))
- 截断到“前 10 个显示单位”时，[]rune 可能切在 ZWJ 序列中间，导致显示异常
- 简单场景（纯中文+ASCII）用
[]rune足够 - 涉及昵称、评论、富文本等用户输入，必须用
golang.org/x/text/segment或golang.org/x/text/unicode/norm -
utf8.RuneCountInString(s)和len([]rune(s))结果一致，但前者不分配内存，优先用它
从 string → rune → string，编码合法性不能自动保证
手动改 []rune 后转回 string，大多数情况没问题，但以下情形会悄悄出错：
- 写入非法 rune（如代理区值
0xd800–0xdfff），转 string 后变成（U+FFFD） - 读 GBK 文件后没转 UTF-8，直接当 string 处理，
for range会解码失败，部分位置返回0xfffd - 传给 syscall 或 C 函数前，用
utf8.ValidString(s)快速校验，避免底层崩溃
真正容易被忽略的是：文件或 HTTP body 的原始编码未知时，别急着遍历——先确认 Content-Type 或 BOM，再用 golang.org/x/text/encoding 转换。否则 for range 走得再对，数据源头已经错了。
