utf8.valid 返回 false 仅表示字节序列不符合 utf-8 编码规则，并不意味数据损坏，而是说明该字节流不能被合法解释为 utf-8；常见原因是源数据实为 gbk 等编码却被误作 utf-8 处理。
utf8.Valid 为什么返回 false 不代表数据损坏
它只回答“这段字节能不能被当作合法 UTF-8 解释”，不评价内容是否有意义。常见现象是：strings.Contains(s, "中文") 失败，但肉眼可见有中文——大概率是源数据实际为 GBK 编码，被当 UTF-8 读入；utf8.Valid([]byte(s)) 自然返回 false，且后续 range s 可能 panic 或截断。
Go 字符串本质是只读字节序列，编码靠外部约定。非法字节不是“错误”，而是“未按 UTF-8 解释的原始字节”。别急着擦除，先确认来源和真实编码。
别用 strings.ToValidUTF8 预处理关键字段
strings.ToValidUTF8 是 Go 1.13+ 加入的兜底函数，会把所有非法 UTF-8 序列替换成 U+FFFD（）。它解决的是显示问题，不是数据问题——原始语义已丢失，且不可逆。
- 用它预处理日志或索引字段，会导致搜索失效：比如原始是 GBK 编码的 “张三”，转成
后，strings.ReplaceAll也救不回来 - 对大文本（>1MB）性能明显下降，因为要全量扫描 + 替换
- 它掩盖了真正的问题：你本该知道这串字节来自哪里、是什么编码
如何安全读取并校验文件中的 UTF-8 行
用 bufio.Reader.ReadString('\n') 读出一行后，立即调用 utf8.ValidString(line) 判断有效性。无效时不要直接丢弃，而应记录位置、原始字节（[]byte(line)），再决定下一步：
- 若明确知道是 GBK 编码，用
golang.org/x/text/encoding/simplifiedchinese.GBK.NewDecoder().Bytes()转码 - 若只是部分乱码（如 Windows 记事本 BOM 后残留），可用
utf8.FullRune定位首个非法字节位置，选择截断或报错 - 避免用
bytes.Runes([]byte(line))校验——它静默替换为U+FFFD，无法检测问题
string(0x80) 为什么生成两个字节
Go 把整数转字符串时，不是塞原始字节，而是把它当 rune 编码成 UTF-8。0x80 对应 Unicode 码点 U+0080，必须用两字节表示：0xc2 0x80。所以 len(string(0x80)) == 2 是规范行为，不是 bug。
需要精确插入单字节 0x80？只能绕过 UTF-8 编码：
- 用十六进制转义：
"\x80" - 或显式构造字节切片：
string([]byte{0x80})
任何试图用 string(n) 往二进制协议里“拼字节”的操作，只要 n > 0x7f，都会悄悄变成多字节——这是最容易被忽略的底层陷阱。
