len(s) 返回字节数而非字符数，因go字符串底层是utf-8字节序列；“hello世界”len为11但实际8个rune，需用utf8.runecountinstring(s)获取准确字符数。
len(s) 为什么不能直接当“字符数”用
因为 len(s) 返回的是字节数，不是人眼看到的字符个数。UTF-8 编码下，英文、数字占 1 字节，中文通常占 3 字节，emoji 可能占 4 字节。比如 "Hello世界" 的 len() 是 11，但实际只有 8 个字符（5 英文 + 3 中文）。
常见错误现象：前端显示字数超限却没报错、API 校验长度不一致、日志摘要截断后末尾乱码。
- 别把
len(s) > 100当作“超过 100 个字”的判断依据 - 产品需求说“限 25 字”，必须按 Unicode 码点（rune）计数，不是字节
-
utf8.RuneCountInString(s)是最轻量、最安全的标准库方案，无需分配新切片
utf8.RuneCountInString() vs []rune(s) 的取舍
两者都返回真实字符数，但行为和开销不同：
-
utf8.RuneCountInString(s)：只遍历、不解码内容，不分配内存，适合纯计数场景 -
len([]rune(s))：强制解码并拷贝全部 rune，产生额外堆分配，仅当你后续还要用[]rune做切片或遍历时才值得 - 对超长文本（如 1MB 日志片段），反复调用
[]rune(s)可能触发 GC 频繁，而RuneCountInString几乎无开销
示例：utf8.RuneCountInString("a\u2022b\U0001F600c") → 5（含 bullet、emoji）；len([]rune("a\u2022b\U0001F600c")) 也返回 5，但多一次内存拷贝。
含非法 UTF-8 字节时怎么安全计数
用户粘贴、第三方接口传入的字符串可能含损坏的 UTF-8 序列（如截断的中文、二进制混入）。此时 utf8.RuneCountInString(s) 仍会返回“尽力而为”的字符数（把非法字节当单字节 rune），但不会 panic。
- 若需严格区分合法/非法，用
utf8.DecodeRuneInString()循环手动解码，检查每个rune是否为utf8.RuneError - 多数业务场景（如字数限制、摘要生成）可接受“尽力计数”，不必主动校验——毕竟 UI 层也不会渲染
\xFF\xFF - 真正要过滤或修复时，建议用
strings.ToValidUTF8(s)（Go 1.22+）或bytes.ToValidUTF8()预处理
多国语言混排时的“字数”定义差异
所谓“字符数”在不同语境下含义不同，必须和产品对齐：
- 纯 Unicode 码点计数（默认）：
utf8.RuneCountInString(s)，适用于中文、日文、韩文、阿拉伯文、emoji - 中英混合特殊规则（如“2 英文字母 = 1 字”）：需单独遍历，用
unicode.IsLetter()/unicode.IsDigit()/unicode.IsHan()分类统计 - 视觉宽度估算（如终端对齐）：需用
github.com/mattn/go-runewidth，它考虑全角/半角，但非标准库
最容易被忽略的是：同一个字符串，在 iOS 输入法、微信、网页 textarea 中上报的“length”可能不同——它们各自做了 normalization 或 surrogate pair 处理。服务端统一用 utf8.RuneCountInString 是最可控的底线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
