Go utf8.RuneCountInString 与 len 的统计结果怎么解释

Go 里看到 len(s) 和 utf8.RuneCountInString(s) 得出不同结果，并不代表字符串被损坏。len 统计的是字符串占用的字节数，RuneCountInString 统计的是 UTF-8 解码后包含多少个 rune；英文通常一字节一个 rune，中文等字符可能占用多个字节。

len 和 RuneCountInString 分别在数什么

Go 的 string 本质上是一段不可变字节序列。UTF-8 会把一个 Unicode 码点编码成 1 到 4 个字节，所以“字节长度”和“rune 数量”天然可能不同。

例如 "Hello, 世界" 中，ASCII 字符和空格各占 1 个字节，“世”和“界”各占 3 个字节，因此字节数会大于 rune 数量。这个差异是编码结果，不是 len 的 bug。

遇到乱码时先检查 UTF-8 是否有效

RuneCountInString 是 RuneCount 的字符串版本。它能给出一个计数，但不能替代输入校验。官方文档说明，错误或不完整的 UTF-8 编码会按单个宽度为 1 的 rune 处理；因此无效输入也可能得到一个看似合理的数字。

排查外部文件、消息队列或 HTTP 数据时，先把“长度是多少”和“编码是否合法”拆成两个问题：

package main

import (
    "fmt"
    "unicode/utf8"
)

func main() {
    text := "你好"

    // len 统计 UTF-8 字节数，RuneCountInString 统计 rune 数量。
    fmt.Println("bytes:", len(text))
    fmt.Println("runes:", utf8.RuneCountInString(text))

    // 有效性检查要单独做，不能用长度结果代替。
    fmt.Println("valid UTF-8:", utf8.ValidString(text))
}

对正常的中文字符串，上例的字节数是 6，rune 数量是 2，ValidString 为 true。如果字符串来自不可信的字节转换，校验失败时应回到数据入口确认编码协议，而不是简单把长度阈值调大。

按使用场景选择字节数、rune 数量还是可见字符

最容易出错的是把“字符数”当成一个固定概念。接口限制 20 KB 时，应该比较 len(s)；数据库字段或协议规定最多 20 个 Unicode 码点时，可以比较 utf8.RuneCountInString(s)。如果要按 rune 截断，不要直接用 s[:20]，因为那是按字节切片，可能切到多字节编码中间。

还要留意用户看到的“一个字符”可能由多个 Unicode 码点组成，例如基础字母和组合重音，或者某些表情符号序列。rune 统计适合 Go 层的编码边界，不等于完整的用户可见字符（grapheme cluster）计数；真正的 UI 字符限制应采用明确支持该规则的文本处理方案。

最小检查清单：三项输出分别回答三个问题

1. 要传输或存储多少字节？看 len(s)。
2. 字符串里有多少个 UTF-8 解码单元？看 utf8.RuneCountInString(s)。
3. 输入是不是完整有效的 UTF-8？看 utf8.ValidString(s)。

这三个结果应该一起解释。只看 len 会误把中文当成多个“字符”，只看 rune 数量又可能放过无效输入；把计数口径和数据有效性分开，排查结果才不会被表象带偏。

常见问题

为什么 range 遍历出来的数量通常接近 RuneCountInString？

range 会按 UTF-8 解码得到 rune，并在遇到错误编码时产生替代 rune；它和字节下标遍历不是同一口径。需要判断输入是否合法时，仍要显式调用 utf8.ValidString。

可以用 []rune(s) 的长度代替 RuneCountInString 吗？

可以得到相近的 rune 数量，但转换会分配新的 rune 切片。如果只需要计数，直接调用 utf8.RuneCountInString 更清楚，也避免无意义的转换。

len([]rune(s)) 是字节数吗？

不是。[]rune 的每个元素通常是一个 Go 的 rune 值，len([]rune(s)) 统计元素个数；它既不是原始 UTF-8 字节数，也不保证等于用户看到的字符数。