go字符串默认是utf-8字节序列，len()返回字节数而非字符数，s[0]取首字节易致乱码；正确处理需用rune、utf8包函数及unicode正规化。
Go 里字符串默认就是 UTF-8 编码，但“转换”这个词容易误导——你通常不需要把 string “转成 UTF-8”，它本来就是；真正要做的，是把字节序列正确解码为逻辑字符（rune），再按 Unicode 规则处理。
为什么不能直接用 len() 或 s[0] 处理中文/emoji
因为 len("你好") == 6，不是 2；s[0] 拿到的是第一个字节 0xE4，不是“你”。这是 UTF-8 可变长编码的必然结果：中文占 3 字节，✅ 占 4 字节。直接按字节操作会截断、越界、返回乱码或 \uFFFD。
- 错误写法：
if s[0] == '你'—— 编译失败（类型不匹配），或运行时 panic（越界） - 错误写法：
strings.HasPrefix(s, "✅")—— 按字节比，但 ✅ 在不同环境可能被拆分或重组，不可靠 - 正确思路：先确认你要的是“第几个字符”，还是“前 N 个字节”，还是“以某个 Unicode 字符开头”
utf8.DecodeRuneInString 是轻量级首字符解析首选
它不分配内存、不解码整个字符串，只取第一个 rune 和它的字节长度，适合做前缀判断、安全截断、协议头解析等场景。
- 返回值：
r rune和size int；若输入为空或非法 UTF-8，size == 0，此时r == 0 - 判断是否以 emoji 开头：
r, size := utf8.DecodeRuneInString(s); if size > 0 && r == '✅' { ... } - 安全截取前两个字符：
r1, sz1 := utf8.DecodeRuneInString(s); r2, sz2 := utf8.DecodeRuneInString(s[sz1:]); result := s[:sz1+sz2] - 注意：别在循环里反复调用它做全量遍历——性能不如
for i, r := range s
需要随机访问或批量处理时，用 []rune(s) 而非 strings.Split
strings.Split(s, "") 会把每个字节当一个字符串切出来，对中文直接崩；而 []rune(s) 是 Go 内置的 UTF-8 解码机制，能正确分离出每个 Unicode 码点。
- 获取第 3 个字符：
rs := []rune(s); if len(rs) > 2 { third := rs[2] } - 转大写（支持德语 ß、土耳其语 I）：
upper := make([]rune, len(rs)); for i, r := range rs { upper[i] = unicode.ToUpper(r) } - 性能提醒：对超长字符串（如 MB 级日志）频繁转
[]rune会触发内存分配和 GC 压力；高频场景建议用range流式处理，或复用[]rune缓冲区 - 判断汉字别用正则
\p{Han}——unicode.Is(unicode.Han, r)更快、无需导入额外包、且覆盖扩展 A/B 区
Unicode 规范化不是可选项，而是数据一致性前提
同一个“é”可以是单个码点 \u00E9（NFC），也可以是 e + \u0301（NFD）。数据库存、API 比对、map key 查找时若不统一，就会出现“看起来一样却判为不同”的问题。
- 必须用
golang.org/x/text/unicode/norm包做标准化：norm.NFC.String(s)或norm.NFD.Bytes([]byte(s)) - 别在存储前用
strings.ToLower就完事——它不处理规范化；大小写 + 规范化要一起做 - HTTP header、JWT claim、JSON key 这类对相等性敏感的场景，漏掉规范化会导致线上静默不一致
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
