因为len()返回字节数而非字符数，utf-8中中文占3字节，应使用utf8.runecountinstring(s)准确计数；判断utf-8合法性用utf8.validstring(s)，遍历中文须用for range避免下标越界。
中文字符串长度统计为什么不能用 len()？
因为 len() 返回的是字节数，不是字符数。UTF-8 中一个中文字符占 3 字节，len("你好") 是 6，但你真正想问的是“有几个汉字”——这得按 Unicode 码点（rune）算。
- 直接用
len([]rune(s))最直观，但会分配新切片，小字符串没问题，高频调用或大文本时有 GC 压力 -
utf8.RuneCountInString(s)更轻量，内部遍历不分配内存，推荐用于纯计数场景 - 别用
strings.Count()或正则匹配中文范围，既不准（漏掉 emoji、日文平假名等）又慢
如何快速判断字符串是否全是合法 UTF-8？
Go 的字符串字面量和标准库默认都假设是 UTF-8，但外部输入（如 HTTP body、文件读取、数据库字段）可能混入非法字节序列，比如截断的 UTF-8 或 Windows-1252 乱码。这时候不能只靠 utf8.ValidString() 就完事。
-
utf8.ValidString(s)是最直接的检查函数，返回true仅当整个字符串每个字节都符合 UTF-8 编码规则 - 注意：它不校验语义合法性（比如未分配的码点、代理对 surrogate pair），只管编码格式
- 如果需要容错（如把非法字节替换成 ），用
strings.ToValidUTF8(s)（Go 1.22+），旧版本得手动遍历 +utf8.DecodeRuneInString() - 常见错误：用
unicode.IsLetter(rune(c))前不先验证字符串合法性，可能导致 panic 或误判
遍历中文字符串时为什么 for range 比下标安全？
因为中文字符在 UTF-8 里不是固定宽度，用 for i := 0; i 取 <code>s[i] 得到的是字节，不是字符，容易切在中间，导致乱码或 utf8.DecodeRune 返回 utf8.RuneError。
-
for _, r := range s自动按 rune 拆分，r就是完整字符（如 '你'、'好'、'?'），这是 Go 对 UTF-8 的原生支持优势 - 如果还需要索引位置（比如记录第几个汉字），用
for i, r := range s，这里的i是字节偏移，不是 rune 索引；要 rune 索引得自己累加计数 - 性能上，
range比[]rune(s)遍历快且零分配，除非你要随机访问某个 rune 位置
处理混合中英文时要注意哪些边界情况？
真实文本往往中英混排、夹带数字、标点、emoji，甚至控制字符。光看“是不是中文”远远不够。
立即学习“go语言免费学习笔记（深入）”；
-
unicode.Is(unicode.Han, r)能较准识别汉字（含扩展 A/B 区），但不会匹配日文汉字（unicode.Hiragana/Katakana）、韩文（unicode.Hangul），按需补充 - emoji 多为多 rune 组合（如 ?? 是 4 个 rune），
utf8.RuneCountInString()会如实计数，但业务上可能希望“一个 emoji 算一个单位”，得用golang.org/x/text/unicode/norm归一化或专用 emoji 库 - 空格、全角/半角标点、零宽字符（如
\u200b）会影响显示长度和光标位置，前端渲染和后端校验逻辑不一致时容易出 bug - 别依赖
len(s) 做截断，用户看到的“长度”是视觉宽度（中文≈2英文），真要限制显示宽度得用 <code>runewidth.StringWidth()这类第三方计算
Unicode 处理最麻烦的从来不是“怎么写”，而是“什么才算合法输入”——不同来源的数据契约差异太大，校验策略得跟着上下文走。
