len("中文") 返回字节数而非字符数，因Go字符串底层为UTF-8字节序列，“中文”占6字节但仅2个rune；需用utf8.RuneCountInString获取正确字符数。
为什么 len("中文") 不等于字符个数
Go 字符串底层是字节序列，len() 返回的是字节数，不是 Unicode 字符（rune）个数。比如 "你好" 是 2 个 rune，但 len("你好") 是 6（UTF-8 编码下每个汉字占 3 字节）。直接用 len() 判断“字符串长度”在含中文、emoji 或其他非 ASCII 字符时必然出错。
- 常见错误现象：
if len(s) > 10 { panic("too long") }导致中文输入被误截断或拒绝 - 使用场景：表单校验、日志截断、数据库字段长度限制（如 MySQL
VARCHAR(20)指 20 个字符，不是 20 字节） - 性能影响：
utf8.RuneCountInString(s)需遍历整个字符串解析 UTF-8 编码，比len()慢一个数量级；高频调用时注意缓存结果
utf8.RuneCountInString 的正确用法和边界情况
这是标准库中唯一推荐的、安全获取字符串 rune 数量的方式。它内部按 UTF-8 规则逐段解码，能正确处理所有合法 Unicode 字符，包括 emoji 组合序列（如 ??）——但注意，它不“理解” emoji 语义，只按编码单元计数。
- 参数差异：只接受
string，不支持[]byte；若你手头是字节切片且确定为 UTF-8，先转string（无拷贝开销）再调用 - 兼容性：Go 1.0+ 全版本可用，无替代方案
- 容易踩的坑：
utf8.RuneCountInString("\xff\xfe")对非法 UTF-8 序列仍返回计数（这里是 2），不会 panic 或报错；需额外用utf8.ValidString()校验有效性 - 简短示例：
import "unicode/utf8" s := "Hello 世界 ?" n := utf8.RuneCountInString(s) // n == 11
需要截取前 N 个字符时，别用 [:] 切片
直接用 s[:n] 是按字节截断，极易产生乱码。例如 "你好"[0:2] 得到非法 UTF-8 片段 "\xe4\xbd"，后续打印或 JSON 序列化可能失败或显示。
- 正确做法：用
for range遍历 rune，或借助strings.RuneCount+utf8.DecodeRuneInString手动解码截断 - 更实用的方案：用
golang.org/x/text/unicode/norm或第三方库如runes（runes.Take(s, n)），但仅当项目已引入或对性能无严苛要求时选用 - 轻量替代：
func substrRune(s string, n int) string { if n <= 0 { return "" } for i, r := range s { if i >= n { return s[:i] } if r == utf8.RuneError && (i == 0 || s[i-1] == utf8.RuneError) { break // 遇到非法编码提前停 } } return s }
emoji 和组合字符让“长度”变得更复杂
像 ??（程序员 emoji）本质是多个 Unicode 码点通过 ZWJ 连接而成，utf8.RuneCountInString 会将其计为 4 个 rune（? + ZWJ + ? + ZWJ？实际取决于具体序列），但用户感知是“1 个图标”。这时候“视觉长度”和“rune 长度”已经不是一回事。
立即学习“go语言免费学习笔记（深入）”；
- 使用场景：前端显示计数、富文本光标定位、输入法限制——这些需求往往要依赖图形库或 ICU 规则，Go 标准库不处理
- 现实妥协：多数后端接口只需保证存储和传输合法 UTF-8，按
utf8.RuneCountInString校验即可；真正需要视觉长度的环节，应交由客户端计算 - 容易被忽略的点：日志或调试时用
fmt.Printf("%q", s)查看原始 rune 序列，比fmt.Println(s)更可靠
