rune 是 int32 别名，无编码校验；string 为 utf-8 字节序列，len 返回字节数；[]rune(s) 解码为 unicode 码点，len 才近似“字符数”；range 遍历隐式按 rune 迭代，i 为起始字节索引。
Go 里 rune 不是“字符类型”，而是 int32 别名
很多人以为 rune 是 Go 专门用来表示“Unicode 字符”的新类型，其实它只是 int32 的别名：type rune int32。它不带任何运行时语义，也不做编码校验——传一个非法的 UTF-8 码点（比如 0x110000）给 rune 变量，编译器完全不管。
真正区分“字节”和“Unicode 码点”的，是 Go 对字符串字面量、[]byte 和 []rune 的底层处理方式：
-
string永远是 UTF-8 编码的字节序列，len(s)返回字节数，不是“字符数” -
[]rune(s)才会把string解码成 Unicode 码点序列，此时len([]rune(s))才接近人眼感知的“字符个数” - 中文、emoji、带变音符号的拉丁字母（如
é）往往占多个字节，但通常对应一个rune
用 range 遍历字符串时，隐式按 rune 迭代
这是 Go 最常被误解也最实用的机制：for i, r := range s 中的 r 是 rune，且 i 是该 rune 在原始字符串中的起始字节索引（不是 rune 索引）。这和 Python 的 for c in s 行为一致，但底层实现更轻量——Go 没有预先解码整个字符串。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 写
for i := 0; i ：拿到的是字节，中文会乱码或 panic（越界） - 误以为
i是“第几个字符”，结果发现i跳跃增长（如中文从 0→3→6），导致逻辑错位 - 想取“第 N 个字符”却直接用
s[N]，实际拿到的是某个中文的第一个字节（如中的0xe4）
正确做法：要取第 n 个 Unicode 字符，必须先转 []rune：rns := []rune(s); if n 。注意这会分配内存，高频场景需权衡。
strings.Count 和 strings.IndexRune 的行为差异
strings.Count(s, substr) 统计子串出现次数，substr 是 string，所以它按 UTF-8 字节匹配；而 strings.IndexRune(s, r) 按 Unicode 码点查找，r 是 rune。两者底层走不同路径，结果可能不一致。
典型场景：
- 查中文字符位置：
strings.IndexRune("你好", '好')返回3（字节偏移），而strings.Index("你好", "好")也返回3，表面一样，但原理不同 - 查 emoji：
strings.IndexRune("??", '?')返回0，但strings.Index("??", "?")也返回0—— 因为连字 emoji（ZJW 序列）在 UTF-8 中仍是合法码点组合，Index也能“碰巧”对上 - 真正危险的是混合场景：比如
s = "café"，strings.Count(s, "é")返回1（é是单个rune，UTF-8 编码为 2 字节），但若你用é的组合形式（e + ◌́），Count就找不到——因为那是两个rune
结论：只要目标是 Unicode 抽象字符，优先用 IndexRune、ContainsRune 等带 Rune 后缀的函数；涉及子串（尤其是多字符、含标点或变音符号）时，必须确认输入是规范化的 UTF-8。
JSON 解析时 json.Unmarshal 对 rune 字段的静默处理
Go 的 json 包默认把 JSON 字符串解到 string 字段，不会自动转成 []rune。如果你定义结构体字段为 rune，比如：
type T struct {
C rune `json:"c"`
}
那么传入 {"c": "a"} 会失败（json: cannot unmarshal string into Go value of type rune），因为 rune 是整数类型，JSON 解析器期望数字，比如 {"c": 97} 才能成功。
容易踩的坑：
- 误以为
rune字段能接收单字符字符串，结果解码失败且错误信息不直观 - 想用
rune存储用户输入的“首字符”，却在 JSON 层暴露了类型不匹配问题 - 前端传来
"?"，后端用rune字段接收 → 直接报错，而用string就一切正常
务实建议：JSON 接口一律用 string 接收文本，需要按码点处理时再显式转 []rune；除非你明确控制上下游都传数字码点（极少见）。
Unicode 处理真正的复杂点不在 rune 类型本身，而在字符边界判断（grapheme clusters）、规范化（NFC/NFD）、以及字体渲染层对 ZWJ 序列的支持——这些 Go 标准库都不管，得靠 golang.org/x/text 等第三方包。别指望 []rune 一招解决所有“中文/emoji 计数”问题。
