for range遍历字符串得到rune（Unicode码点）而非byte；i为字节偏移量，v为rune类型；修改需转[]rune；统计“人眼字符”应使用grapheme.Clusterer。
for range 遍历字符串拿到的是 rune，不是 byte
Go 的 string 底层是 UTF-8 编码的字节序列，但 for range 会自动解码成 Unicode 码点（rune），也就是你真正想“看到”的字符。如果误以为遍历的是字节，就容易对中文、emoji 或带变体符号的字符（比如 `é` 写成 `e\u0301`）出错。
常见错误现象：
– 用 len(s) 得到字节数，再用 s[i] 下标取值，结果切到 UTF-8 中间字节，打印出乱码或 panic
– 把 for i, v := range s 中的 v 当作 byte 去比较，比如写 v == '中' 是对的，但写 v == 0xe4（UTF-8 第一字节）就错了
-
for range是安全遍历 Unicode 字符的唯一推荐方式，别手写字节解析 -
v的类型是rune（alias ofint32），不是byte或uint8 - 下标
i是字节偏移量，不是字符序号；同一个字符串里，i的步长可能是 1（ASCII）、3（中文）、4（某些 emoji）
遍历时不能用下标修改原字符串
Go 中 string 是不可变的，哪怕你拿到 i（字节位置），也不能写 s[i] = 'x' —— 这行不通，编译直接报错 cannot assign to s[i]。
使用场景：想把字符串里每个汉字替换成星号、或过滤掉 emoji，就不能边遍历边改原串。
立即学习“go语言免费学习笔记（深入）”；
- 需要修改时，先转成
[]rune：rs := []rune(s)，然后遍历rs修改元素，最后再转回string(rs) - 不要用
[]byte(s)替代，它只适合纯 ASCII 场景；一旦含中文，[]byte长度 ≠ 字符数，且修改后可能破坏 UTF-8 结构 - 性能影响：
[]rune(s)是 O(n) 拷贝，对超长文本（如 MB 级日志）要留意分配开销
区分“字符”和“用户感知的字形”（grapheme cluster）
for range 按 rune 切，但一个视觉上的“字符”可能由多个 rune 组成，比如带声调的 `á`（'a' + '\u0301'）或肤色修饰的 ??（多个 code point + joiner）。这时候 for range 会拆成多个迭代项。
错误现象：统计“字符数”显示为 2，但用户只看到 1 个图标；替换时只改了前半部分，留下孤立的 ZWJ 或变体符号。
- 标准库不提供 grapheme cluster 级遍历，得靠
golang.org/x/text/unicode/norm或golang.org/x/text/unicode/grapheme - 如果业务真要按“人眼所见”切分（比如输入法、编辑器、字符计数），必须引入
grapheme.Clusterer，不能依赖for range - 绝大多数后端处理（日志清洗、简单替换、长度校验）用
for range足够；前端展示或富文本才需升级到 grapheme
慎用 strings.IndexRune 配合 for range 做“查找+替换”
有人想一边遍历一边找某个 rune 的位置做替换，于是混用 strings.IndexRune(s, target) 和 for range，结果发现索引对不上 —— 因为 IndexRune 返回字节偏移，而 for range 的 i 也是字节偏移，看似能对齐，但一旦字符串被修改（比如删掉前面几个字符），偏移就失效了。
典型翻车点：循环里调 strings.Replace，再拿新字符串继续 for range，但忘了每次替换都改变了后续所有 i 的含义。
- 要么全用
[]rune操作（统一在 rune 层处理索引和修改） - 要么用
strings.Builder累积结果，遍历时只读不改原串 - 避免在循环体内反复调
strings.*类函数处理同一字符串，尤其是涉及位置信息时
