utf8.Valid是最轻量的UTF-8语法校验函数，仅接受[]byte输入、不分配内存、不panic、不转rune；它不校验语义合法性（如代理对、超大码点），且不可直接用于string类型，须显式转换为[]byte(s)以保原始字节完整性。
utf8.Valid 是最轻量、最直接的验证方式，它不分配内存、不 panic、不转换 rune，只做纯字节语法校验。传入 []byte 即可，别用 utf8.ValidString 预先转成 string——那会掩盖原始字节问题。
为什么不能直接对 string 调用 utf8.Valid
utf8.Valid 函数签名是 func Valid(b []byte) bool，它只接受 []byte。如果你写 utf8.Valid(s)（其中 s 是 string），Go 会报错：cannot use s (type string) as type []byte in argument to utf8.Valid。必须显式转成 []byte(s)。
常见错误是误以为 string 和 []byte 可以隐式互换，尤其在处理含 \x00 的字符串时，隐式转换可能触发 Cgo 边界异常；更隐蔽的问题是：一旦 string 已被 Go 运行时“修复”过（比如从文件读取后自动替换了非法序列为 \uFFFD），再转 []byte 就不是原始字节了。
- 验证原始数据时，永远优先在
[]byte阶段调用utf8.Valid - 如果已拿到 string，且确定它没被 runtime 修改过，可用
utf8.ValidString(s)，但它内部仍是转[]byte再校验，多一次转换开销 - 不要依赖
for _, r := range s是否 panic 来判断——Go 版本不同行为不一致，且静默跳过字节无法定位问题
utf8.Valid 只校验语法，不保证语义合法
它只检查字节序列是否符合 UTF-8 编码规则：前导字节范围是否正确、后续字节高位是否为 10xxxxxx、总长度是否匹配等。它不管这个 rune 是否属于 Unicode 未分配区、是否是代理对（surrogate pair）、是否超长编码（如用 2 字节表示 ASCII 字符）。
立即学习“go语言免费学习笔记（深入）”；
这意味着：
-
utf8.Valid([]byte{0xED, 0xA0, 0x80})返回true（这是 UTF-8 编码的 U+D800，一个非法代理码点，但字节结构合法） -
utf8.Valid([]byte{0xF4, 0x90, 0x80, 0x80})返回true（U+140000，超出 Unicode 当前最大码点 U+10FFFF，但字节格式合规） - 若需语义级校验（比如过滤掉代理对或超大码点），得额外用
unicode.IsPrint或手写白名单逻辑
遇到非法 UTF-8 字节时，别用 strings.ToValidUTF8 “擦除”
strings.ToValidUTF8 是 Go 1.13+ 提供的兜底函数，它把所有非法 UTF-8 序列替换成 \uFFFD。但它解决的是显示问题，不是数据问题。
典型陷阱：
- 用它预处理日志字段后做
strings.Contains搜索中文，结果匹配不到——因为原始 GBK 字节已被破坏，变成 字符 - 索引前调用它，导致倒排索引里存的是替换后的乱码，无法回溯原始语义
- 对 >1MB 文本调用，性能明显下降，因为它要全量扫描 + 分配新字符串
真正该做的是：用 utf8.FullRune 或 utf8.DecodeRune 定位首个非法位置，然后决定是丢弃整段、报错、还是交给 golang.org/x/text/encoding 做有损转码（比如从 GBK 转 UTF-8）。
关键点始终是：验证只是第一步，后续怎么处理非法字节，取决于你手上有没有编码线索。没有线索时，utf8.Valid 返回 false 不代表数据损坏，只说明它不是 UTF-8——可能是 GBK、Shift-JIS、甚至二进制残留。盲目擦除，比不验证更危险。
