Go读GBK文件需用golang.org/x/text/encoding/simplifiedchinese.GB18030.NewDecoder().Bytes()解码，写入时用NewEncoder().String()编码，避免UTF-8校验panic；解码器非线程安全，不可复用。
golang 读取 GBK 文件时 panic: invalid UTF-8 sequence
Go 默认所有 string 和 []byte 都按 UTF-8 处理，直接用 os.ReadFile 读 GBK 编码的文件，内容本身不是无效字节，但后续若传给 fmt.Println、json.Marshal 或正则匹配，就可能触发 invalid UTF-8 sequence panic —— 因为 Go 运行时会在某些边界检查中验证 UTF-8 合法性。
真正要做的不是“修复字符串”，而是「在字节层面完成编码转换」：把原始 GBK 字节流解码成 UTF-8 字符串，或把 UTF-8 字符串编码回 GBK 字节流。
- 别用
strings.ToValidUTF8或手动替换\ufffd—— 这只是掩盖问题，原文本语义已丢失 - 必须用
x/text/encoding+ 对应的encoding.RegisterEncoding注册器（GBK 不在标准库默认注册列表里） -
golang.org/x/text/encoding/simplifiedchinese提供了GBK和GB18030，后者是前者的超集，兼容性更好
用 simplifiedchinese.GB18030.NewDecoder() 解码 GBK 字节流
GB18030 解码器能正确处理纯 GBK 数据（GB18030 向下兼容 GBK），且比手写 GBK 解码器更稳——simplifiedchinese.GBK 在某些边缘双字节序列上会误判，而 GB18030 实现更成熟。
注意：解码器不是线程安全的，不要复用同一个 Decoder 实例处理多个 goroutine 的数据。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 解码失败默认返回 error，不自动跳过；如需容错，用
decoder.Bytes(s, &utf8)+encoding.ReplaceUnsupported替换策略 - 别直接对
io.Reader套一层transform.NewReader就完事——如果源 Reader 是带缓冲的（比如bufio.Reader），可能因内部 read buffer 导致部分字节被提前消费，解码错位 - 推荐先读完整字节切片，再解码：
bytes, _ := os.ReadFile("a.txt"); utf8Bytes, _ := simplifiedchinese.GB18030.NewDecoder().Bytes(bytes)
写入 GBK 文件时中文变成乱码或空字符串
常见错误是把 UTF-8 字符串直接 WriteString 到文件，或用 fmt.Fprint 输出——操作系统/编辑器按 GBK 解释这些 UTF-8 字节，自然显示为乱码。本质是「没做编码转换」。
必须显式将 UTF-8 字符串编码为 GBK 字节，再写入：
- 用
simplifiedchinese.GB18030.NewEncoder().String("你好")得到[]byte，再写入文件 - 编码失败时返回 error 和部分成功字节，不能忽略 error；尤其当字符串含 Unicode 扩展区字符（如 emoji、生僻汉字），GB18030 虽支持大部分，但仍有少量未收录字会失败
- Windows 记事本默认用 GBK 打开无 BOM 的文本，但 VS Code、Sublime 等默认 UTF-8 —— 写入后务必用支持 GBK 的工具验证，别只看编辑器预览
为什么不用 iconv 或 cgo 调用系统库
有人试过用 cgo 包装 libiconv，短期可行，但引入 C 依赖后：交叉编译失效（尤其 Windows → Linux）、静态链接麻烦、容器镜像体积翻倍、CI 构建环境需额外装 devtoolset。
x/text/encoding 是纯 Go 实现，无 CGO，GOOS=windows GOARCH=amd64 go build 直出可执行文件，部署干净。
-
x/text库更新慢，但simplifiedchinese的 GB18030 实现自 v0.3.0 起已稳定，无已知严重 bug - 性能够用：单次解码 1MB GBK 文本约 3–5ms（i7-11800H），远低于磁盘 IO 开销，不必微优化
- 唯一硬伤：不支持 GBK 的“微软私有区”（如 U+E000–U+F8FF 中的部分造字），但这类字几乎只存在于老旧政务系统，新项目基本遇不到
编码转换这事，核心就两点：读的时候用 GB18030.NewDecoder().Bytes()，写的时候用 GB18030.NewEncoder().String()。中间所有字符串操作都按 UTF-8 安排，别碰原始 GBK 字节。容易被忽略的是——解码/编码器实例不能跨 goroutine 复用，也别试图缓存它们来“提升性能”。
