Go字符串底层是UTF-8编码的只读字节序列，len(s)返回字节数而非字符数；中文占3字节、emoji如“?”占4字节；遍历应使用range获取rune，避免用索引截取或手动拼接非法UTF-8。
Go字符串底层是UTF-8，不是Unicode码点
Go的string类型本质是只读字节序列，编码为UTF-8。这意味着一个中文字符（如"中"）占3个字节，而一个emoji（如"?"）可能占4个字节——它由一对UTF-16代理对（surrogate pair）编码而来，在UTF-8中被转义为4字节序列。你不能靠len(s)得到“字符个数”，那只是字节数。
常见错误现象：
– for i := 0; i 会把emoji拆成乱码字节输出<br>
– <code>s[0] 取到的是第一个UTF-8字节，不是第一个“字符”
- 要用
range遍历：它自动按rune（Unicode码点）解码，?算1个rune，哪怕底层4字节 - 需要索引访问时，先用
[]rune(s)转切片，再下标取值（注意：这会分配新内存，大字符串慎用） -
utf8.RuneCountInString(s)才是真正的“字符数”，对应人眼看到的符号个数
代理对在Go里不会单独出现，但需警惕无效UTF-8
UTF-16代理对（U+D800–U+DFFF）在合法UTF-8中**永远不会单独存在**——它们只作为4字节emoji/罕见汉字的内部编码成分。Go的string和range完全屏蔽了代理对概念；你拿到的每个rune都是完整码点（≥U+10000），不会看到U+D800这类孤立代理。
真正要防的是损坏数据：
– 从外部（如HTTP body、文件）读入的字节流若含非法UTF-8（比如截断的4字节emoji），range会把出错位置当0xFFFD（）处理，后续rune偏移全乱
- 用
utf8.Valid([]byte(s))预检字符串是否有效UTF-8 - 解析JSON时，
encoding/json默认拒绝含无效UTF-8的字符串，避免静默损坏 - 若必须容忍损坏，用
strings.ToValidUTF8(s)（Go 1.22+）或手动替换0xFFFD
正则匹配emoji或宽字符必须用\p{Emoji}而非.或\w
标准正则中的.匹配单个UTF-8字节，\w只认ASCII字母数字。想匹配一个完整emoji（如"??"，实际是多个rune连接），或任意Unicode字母，得用Unicode属性类。
常见错误现象：
– regexp.MustCompile(`.`).FindAllString("??", -1) 返回5个碎片（含ZWJ连接符）
– [\u4e00-\u9fa5] 只覆盖常用汉字，漏掉古籍字、扩展B区等
- 匹配任意emoji：用
\p{Emoji}（注意Go正则不支持\p{Extended_Pictographic}这种更全的类） - 匹配所有汉字：用
\p{Han}，比手写区间靠谱得多 - 匹配任意字母（含á, あ, 你好）：用
\p{L}，L代表Letter - 性能提示：Unicode属性正则比ASCII类慢，高频场景建议先用
utf8.RuneCountInString粗筛长度
拼接、截断字符串时，rune边界比字节边界关键
用户昵称截断显示、日志打点限长、数据库字段裁剪……这些操作若按字节切，大概率在emoji中间砍一刀，前端渲染成或乱码。Go没有内置“安全截断”函数，得自己守好rune边界。
立即学习“go语言免费学习笔记（深入）”；
使用场景：
– API返回昵称最多显示5个可见字符（不是5字节）
– 日志行限制100个rune，防止超长截断破坏JSON结构
- 用
for i, r := range s { if count >= 5 { break }; buf = append(buf, r); count++ }手动累积rune - 别用
s[:n]，除非n是经utf8.DecodeRuneInString确认的合法字节偏移 - 第三方库如
golang.org/x/text/unicode/norm可处理组合字符（如带重音的é），但代理对本身无需归一化——Go已保证其完整性
最易被忽略的一点：字符串拼接本身不会引入代理对问题，但如果你从[]byte手动构造字符串（比如网络包解析），且字节流含未配对的代理对，就可能产生非法UTF-8——这时range仍能工作，但下游系统（如浏览器、iOS）可能直接拒收。
