Go中字符串是UTF-8编码的只读字节序列，len(s)返回字节数而非字符数；s[0]取的是首字节而非首字符，遍历需用range避免乱码。
Go 里字符串不是字符数组，string 本质是只读字节序列
这是所有 Unicode 问题的根源。Go 的 string 类型底层是 []byte，不带编码信息；它只是 UTF-8 编码后的字节流。直接用 len(s) 得到的是字节数，不是“字符数”——比如中文字符占 3 字节，len("你好") 是 6，不是 2。
常见错误现象：
• 用 s[0] 取第一个“字符”，结果拿到的是 UTF-8 第一个字节（可能是乱码或非法值）
• for i := 0; i 遍历后索引越界或切出非法字节序列<br>• <code>strings.Split(s, "") 拆出的是字节，不是 rune
- 正确做法：用
for range s—— Go 自动按 UTF-8 解码，每次迭代返回index（字节偏移）和rune（Unicode 码点） - 需要索引访问单个字符？先转成
[]rune：rs := []rune(s)，再用rs[0]；但注意这会分配新 slice，大字符串慎用 - 性能影响：转
[]rune是 O(n) 时间 + O(n) 内存；for range是 O(n) 时间、零额外内存分配
utf8.RuneCountInString 和 utf8.DecodeRuneInString 的实际用途
这两个函数是标准库里最常被忽略的“轻量级 Unicode 工具”。它们不复制数据，只做解码解析，适合做长度校验、首字符检查、安全截断等场景。
使用场景：
• 用户输入昵称限制 10 个 Unicode 字符（不是 10 字节）
• 日志里截取前 20 个字符并加 "…"，不能截在 UTF-8 中间字节上
• 判断字符串是否以某个 emoji 开头（如 ✅ 是单个 rune，但占 4 字节）
立即学习“go语言免费学习笔记（深入）”；
-
utf8.RuneCountInString(s)返回字符数，比len([]rune(s))快且省内存 -
utf8.DecodeRuneInString(s)返回首个 rune 和它占用的字节数，可用于安全前缀匹配：r, size := utf8.DecodeRuneInString(s); if r == '?' { ... } - 别用
strings.HasPrefix(s, "?")做 emoji 判断——它按字节比较，而"?"在源码里是 UTF-8 字节序列，可移植但易被编辑器/IDE 搞乱；用 rune 更稳
正则匹配 Unicode 字符时，\p{Han} 和 \p{Emoji} 要加 (?U)
Go 的 regexp 默认不启用 Unicode 字符类，\p{Han} 这类写法在老版本（error parsing regexp: invalid Unicode class。
容易踩的坑：
• 直接写 regexp.MustCompile(`\p{Han}+`) → panic
• 用 [一-龯] 手动枚举汉字范围 → 漏掉生僻字、扩展区、日韩汉字变体
- 必须加
(?U)标志：regexp.MustCompile(`(?U)\p{Han}+`) -
\p{Emoji}匹配 emoji，但注意它不包含 emoji 修饰符（如肤色），要组合写：(?U)\p{Emoji}\p{Emoji_Modifier}? - 性能提示：Unicode 正则比 ASCII 正则慢不少；若只需判断是否含中文，用
utf8.DecodeRuneInString循环更快
JSON 序列化时 json.Marshal 默认转义非 ASCII 字符
Go 的 json.Marshal 默认把中文、emoji 等转成 \uXXXX 形式，导致输出体积翻倍、可读性差。这不是 bug，是为兼容性做的保守设计。
典型现象：
• API 返回 {"name":"\u4f60\u597d"} 而不是 {"name":"你好"}
• 前端看到一堆 \u，调试困难
- 解决方案：用
json.Encoder并调用SetEscapeHTML(false)（虽然名字叫 HTML，但它控制所有非 ASCII 转义） - 示例：
enc := json.NewEncoder(w)<br>enc.SetEscapeHTML(false)<br>enc.Encode(data)
- 注意：
SetEscapeHTML(false)不影响 HTML 安全性，它只关掉 JSON 层的 Unicode 转义；XSS 防御应在渲染层做
rune 和 string 的区别，而是每次写索引、切片、正则、JSON 输出时，都下意识问一句：“这里操作的是字节，还是字符？” 
