Golang获取字符串长度的实用方法

Go语言中字符串的长度计算暗藏陷阱：len()返回的是UTF-8字节长度而非人类可读的字符数（rune数），例如"你好"用len()得6却实际只有2个字符，正确统计需用utf8.RuneCountInString()；遍历时若用传统for循环按字节索引极易导致乱码或崩溃，必须改用for range或谨慎转换为[]rune；在API限制、日志截断、JSON/HTTP头处理等真实场景中，混淆字节与字符概念会引发隐蔽Bug——掌握这一区别，是写出健壮国际化Go代码的关键第一步。

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 字节）。

正确方式只有两种：

• 用 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 快得多。

到这里，我们也就讲完了《Golang获取字符串长度的实用方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！