Go中len()返回字节长度而非字符数：len("你好")得6，utf8.RuneCountInString()才得2；ASCII字符单字节单rune，中文/emoji等多字节但仅一rune。
Go 里 len() 返回的是字节长度，不是字符个数
这是最常踩的坑：用 len("你好") 得到 6，不是 2。因为 Go 字符串底层是 UTF-8 编码的字节数组，len() 统计的是字节数，不是 Unicode 码点个数。
真正要算“人眼看到的字符数”，得用 utf8.RuneCountInString()：
import "unicode/utf8" s := "Hello 世界" fmt.Println(len(s)) // 13（H-e-l-l-o-空格-世-界，后两个各占 3 字节） fmt.Println(utf8.RuneCountInString(s)) // 8（5 个 ASCII + 3 个汉字）
- ASCII 字符（如英文、数字）一个字节一个 rune，
len()和utf8.RuneCountInString()结果相同 - 中文、emoji、带变音符号的字母（如 “café” 中的 é）通常占多个字节，但只算一个 rune
- 别用
strings.Count()或遍历[]rune来凑数——前者逻辑错，后者开销大
遍历字符串时别直接用 for i := 0; i
这种写法按字节索引走，遇到多字节 rune 会切在中间，导致乱码或 panic（比如取 s[i] 得到非法 UTF-8 字节）。
正确方式只有两种：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
for range s—— 自动按 rune 迭代，i是字节起始位置，r是当前 rune - 显式转成
[]rune再下标访问（仅当真需要随机访问第 N 个字符时才考虑，有内存和性能成本）
反例：for i := 0; i → 可能输出 或崩溃
string 转 []rune 的开销和适用边界
转成 []rune 是深拷贝，会重新分配内存并解码所有 UTF-8 字节。对长文本（比如几 MB 的 JSON 字符串）频繁转换，GC 压力明显。
- 只在需要**随机访问**（如
runes[5]）、**修改单个字符**（需先转切片再拼回 string）或**稳定索引计算**（比如分页截断）时才转 - 单纯遍历、统计、查找？用
for range或utf8.DecodeRuneInString()流式处理更轻量 - 注意：
[]rune长度 = 字符数，但它的每个元素是rune（int32），不是字节，所以len([]rune(s))≡utf8.RuneCountInString(s)
JSON、HTTP header 等场景下长度判断容易混淆
API 返回的 Content-Length 是字节长度；前端 JS 的 "中".length 是字符长度（JS 字符串是 UTF-16，但对 BMP 字符表现像 rune 计数）。两边不一致就会出 bug，比如限制“最多 10 个字符”的输入，在 Go 后端按 len() 检查，用户输 10 个 emoji 就可能超 HTTP body 限制。
- 对外暴露长度限制时，明确文档写清是“Unicode 字符数”还是“UTF-8 字节数”
- 做截断（如日志打点、数据库字段 truncation）必须统一标准：入库前用
utf8.RuneCountInString()判断，截断用[]rune转换后取前 N 个再转回 string - 别依赖
strings.RuneCount()—— 它只是utf8.RuneCountInString()的别名，名字有误导性
字符和字节的界限在 Go 里始终清晰，但一不留神就掉进默认按字节操作的惯性里。尤其是处理用户输入、国际化文本、协议头字段时，多看一眼 len() 和 utf8.RuneCountInString() 的差别，比事后 debug 快得多。
