Go 按字节截取字符串为什么会破坏 UTF-8

Go 里直接写 s[:n]，切的是字节，不是“第 n 个汉字”。ASCII 通常一个字符占一个字节，而中文等 UTF-8 字符可能占三个字节；如果 n 恰好落在多字节序列中间，结果就会包含残缺编码，后续显示可能出现替换字符，utf8.ValidString 也会返回 false。

需要按字符数量截断时使用 []rune；需要严格控制网络、存储或协议字节数时，保留字节切片，但要把截断点回退到合法 UTF-8 起始边界。两者都比盲切 string 更符合真实需求。

Go string 为什么按字节切片会截断 UTF-8

Go 官方对字符串的定义很直接：string 本质上是只读的字节序列，可以保存任意字节。字符串字面量通常来自 UTF-8 源码，但运行时的 string 并不自动承诺永远是合法 UTF-8。索引 s[i] 返回一个字节，len(s) 返回字节数，切片 s[:n] 也沿着字节下标工作。

例如“Go语言”中，G 和 o 各占一个字节，“语”对应三个 UTF-8 字节。把前 3 个字节拿出来，第二个汉字的第一个字节已经被切进来了，但后两个字节没有跟上，因此结果不再是完整的 UTF-8 序列。

先用 utf8.ValidString 把现象定位清楚

不要只根据终端是否显示乱码来判断。显示层可能替换非法字节，也可能因为字体或输出环境掩盖问题。排查时同时打印字节和合法性，能把“视觉异常”变成可判断的输入约束。

package main

import (
    "fmt"
    "unicode/utf8"
)

func main() {
    text := "Go语言"
    broken := text[:3] // 只取前三个字节，故意切入“语”的中间

    fmt.Printf("原始字节: % x\n", []byte(text)) // 查看每个 UTF-8 字节
    fmt.Printf("截取结果: %q\n", broken) // 用转义形式避免显示环境掩盖问题
    fmt.Printf("是否有效 UTF-8: %v\n", utf8.ValidString(broken)) // 直接判断编码完整性
}

这个例子中，broken 的问题不是“中文显示能力不够”，而是切片本身已经缺少一个 UTF-8 序列所需的后续字节。若输入来自外部文件、HTTP 请求或消息队列，还应在边界处决定：是拒绝非法文本、替换非法字节，还是按原始二进制继续传递。

按字符数量截取：用 rune 表达真正的语义

如果产品需求是“最多显示 6 个 Unicode 码点”，就不要拿字节数代替字符数。[]rune(s) 会把字符串解码为 rune，再按 rune 数量取前缀，最后转回 string。它的优点是语义直观，代价是会额外分配 rune 切片；在长文本或高频路径上，需结合缓存、预览长度和分配情况评估。

package main

import "fmt"

func takeRunes(text string, limit int) string {
    if limit  len(runes) { // 上限超过内容时直接返回全部码点
        limit = len(runes)
    }
    return string(runes[:limit]) // 转回 string，保证不切入码点字节
}

func main() {
    fmt.Println(takeRunes("Go语言", 3)) // 结果是“Go语”，不是按三个字节截断
}

这里的“字符”更准确地说是 rune，也就是 Unicode code point。一个用户感知字符可能由多个 code point 组合而成，例如基础字母和组合重音；如果需求是严格的用户感知字符计数，还需要专门的 grapheme cluster 方案，不能把 []rune 说成万能字符切分。

按字节上限截取：回退到合法 UTF-8 边界

上传摘要、协议字段和数据库列有时必须控制字节数，这时把整段文本转换为 rune 再截取，可能增加不必要的复制。可以先拿到字节上限，再从上限位置向左回退，直到该位置是一个 UTF-8 rune 的起始位置；这样保留原有字节接口，同时不把编码切坏。

package main

import (
    "fmt"
    "unicode/utf8"
)

func cutUTF8(text string, byteLimit int) string {
    if byteLimit = len(text) { // 不需要截断时复用原字符串
        return text
    }
    for byteLimit > 0 && !utf8.RuneStart(text[byteLimit]) { // 向左找合法 rune 起点
        byteLimit--
    }
    return text[:byteLimit] // 此处切片点位于 UTF-8 序列之间的合法边界
}

func main() {
    result := cutUTF8("Go语言", 4) // 4 字节预算会回退到“语”之前
    fmt.Printf("%q, valid=%v\n", result, utf8.ValidString(result)) // 结果应保持合法 UTF-8
}

这个实现只保证编码边界，不保证结果包含多少 rune；同样也不处理规范化或用户感知字符。生产代码还应明确 byteLimit 是“最多多少字节”还是“必须恰好多少字节”，以及超限时是否允许返回空串。

最后按输入约束选择方案

常见误区是把 len(s) 当作中文字符数，或者只把问号、乱码归因于终端。真正的检查顺序应是：确认字段语义，再确认输入是否 UTF-8，最后选择按 rune 还是按字节边界截取。这样才能让截断结果与接口契约一致。

相关问题

为什么 range 的索引看起来仍然不是连续的？ 因为索引是当前 rune 在原字符串中的字节起始位置，而不是第几个 rune；每个 rune 的 UTF-8 宽度可能不同。

[]rune 能保证一个用户看到的字不会被拆开吗？ 它能按 Unicode code point 处理，但组合字符、旗帜和部分 emoji 可能由多个 code point 组成，用户感知字符边界需要更高层的文本分割规则。