Go UTF-8 截断后出现替换字符怎么办

Go 字符串切片按字节计算。把 UTF-8 多字节编码切在中间，会留下非法字节序列，后续解码或显示可能呈现替换字符。修复时先判断原始输入是否有效，再按业务需要选择“最多若干字节的完整编码前缀”或“最多若干 rune”；不要直接删除所有替换字符来掩盖数据损坏。

UTF-8 官方文档：https://pkg.go.dev/unicode/utf8

字符串说明：https://go.dev/blog/strings

使用场景：先确认替换发生在哪一层

假设摘要字段被限制为五个字节，输入为 A海风B。直接取前五个字节会保留 A、完整的海，以及风的部分编码。Go 切片本身只是返回这些字节，并不会主动插入 U+FFFD；替换可能发生在后面的 rune 解码、序列化或显示阶段。

排查时保留截断前后的字节长度、UTF-8 有效性和受控的十六进制片段。若原始数据已经非法，边界截断不能恢复丢失内容；若原始内容本来就包含合法编码的替换字符，也不能据此断言数据损坏。

候选方案：字节前缀与 rune 前缀

字节预算适合存储或协议明确限制 UTF-8 字节数的字段，结果可能短于上限；rune 预算适合明确按 Unicode 码点计数的规则，但输出字节数可能更大。直接转成 []rune 后切片可避免拆开码点，却可能在转换时把原有非法编码替换掉，隐藏输入问题。

第一张图用原始字节、合法输入、字节预算、rune 预算、完整前缀和显示文本表示选择关系。合法输入约束截断算法，两个预算限定不同输出属性；完整前缀可以交给显示层，但它不保证视觉字符完整。

对比维度：合法性、预算与视觉边界

输入损坏和预算不足应区别返回。预算为零时返回空前缀是正常结果，非法输入却应得到错误。另一个常见问题是追加省略号：省略号也占 UTF-8 字节，必须先从总预算中扣除，再决定前缀长度。

推荐选择：严格输入的两个原创函数

下面的独立示例先拒绝非法 UTF-8，再逐个完整码点推进结束位置。BytePrefix 返回字节预算内的最长完整前缀，RunePrefix 返回码点预算内的前缀。函数不会把非法输入静默转换成替换字符，也不自动添加省略号。

package main

import (
    "fmt"
    "unicode/utf8"
)

func BytePrefix(s string, limit int) (string, error) {
    if limit  limit-end {
            break
        }
        end += size
    }
    return s[:end], nil
}

func RunePrefix(s string, limit int) (string, error) {
    if limit 

按代码逻辑，五字节预算的结果为 A海，三个 rune 的结果为 A海风；两者都合法，但字节长度不同。这是算法说明，不是测量输出。完整输入合法性检查会扫描整个字符串，生产场景应限制输入大小，不能把此示例宣称为只读取前缀的常量开销算法。

返回的子串可能仍引用较大原字符串的底层数据。若长时间保存很短的前缀，需要结合对象生命周期考虑是否复制，避免把截断与内存释放自动画等号。

不适用情况：流式文本与字素簇

网络分块刚好停在多字节编码中间时，当前块未必是最终非法文本。流式处理应暂存未完成的尾部，与下一块拼接后再解码，并在流结束时决定如何处理剩余数据。不要对每个块独立执行严格输入函数后就认定对端发来了损坏数据。

组合重音、部分 emoji 序列等可能由多个码点组成。按 rune 截断虽然不破坏编码，却仍可能改变显示结果。用户界面的“前十个字符”若意味着字素簇，应使用符合所需 Unicode 分段规则的实现，并另行决定字节预算与截断标记。

第二张图区分完整输入、分块缓冲、解码结果、替换字符、字素簇和显示层。分块缓冲负责保留未完成编码，解码结果与显示层关联；替换字符既可能来自解码错误，也可能原本就合法存在。字素簇属于显示边界，不能从单个 rune 推断。

决策表：把输入错误与截断结果分开

看见 U+FFFD 就说明截断坏了吗？不一定。DecodeRuneInString 返回 RuneError 且宽度为一时表示非法非空编码；合法 U+FFFD 自身是三字节编码。应结合宽度或 ValidString 判断，不能只比较 rune 值。

删掉末尾所有替换字符能恢复吗？不能恢复原字节，也可能删除合法内容。应该在损坏发生前按完整编码边界截断，并保留输入错误。

转换成 []rune 就能修复所有字符问题吗？不能，它不提供字素簇分段，也无法恢复已经丢失的信息。先明确预算单位与非法输入策略，再选择截断方案。