Go 中 UTF-8 ↔ GBK 转换应使用 golang.org/x/text/encoding/gbk + transform，因其无 CGO、稳定且支持流式处理；strings.ToValidUTF8 和 unicode/utf8 仅校验 UTF-8 合法性，不实现编码转换。
直接说结论：go 里做 utf-8 ↔ gbk 转换，别自己造轮子，用 golang.org/x/text/encoding + transform 是目前唯一无 cgo、稳定、可流式处理的方案；所谓“高性能中间件”，本质是避免内存拷贝和全量加载，不是靠算法优化。
为什么不能用 strings.ToValidUTF8 或 unicode/utf8 包修复乱码
这两个包只检查或修正 UTF-8 字节序列合法性，完全不涉及编码转换。你拿一段 GBK 字节（比如 []byte{0xC4, 0xE3}）直接转成 string，得到的是两个非法 UTF-8 码点，utf8.ValidString 返回 false，但调用 strings.ToValidUTF8 只会把它们替换成 ，不是“转成正确中文”。真正要的是解码（GBK → Unicode），不是纠错。
- 常见错误现象：
os.ReadFile("data.txt")后直接fmt.Println(string(data))打印出一堆问号或方块 - 根本原因：Go 的 I/O 操作不识别编码，
string()只是字节到字符串的强制解释，不是解码 - 别试图用正则或字节替换“修”乱码——源数据是 GBK 字节流，不是损坏的 UTF-8
golang.org/x/text/encoding/gbk 和 simplifiedchinese.GBK 用哪个
用 golang.org/x/text/encoding/gbk。它在 2025 年后已取代 simplifiedchinese.GBK（后者被标记为 deprecated）。新包更严格、兼容性更好，尤其对 GBK 扩展区汉字（如“镕”“煊”“珮”）支持完整，而旧包可能静默替换为 ?。
- 安装命令：
go get golang.org/x/text/encoding/gbk - 解码（GBK → UTF-8）：
gbk.Decoder.Bytes(gbkBytes)，失败返回encoding.InvalidUnreadableError，不是 panic - 编码（UTF-8 → GBK）：
gbk.Encoder.Bytes([]byte(utf8Str))，遇到 emoji 或生僻字（无 GBK 码位）会返回 error - 若需容错（如丢弃不可映射字符），用
transform.Chain(gbk.Encoder, transform.RemoveInvalidUTF8)，但生产环境慎用——“丢字”比报错更难排查
流式处理大文件：避免 io.ReadAll 导致 OOM
处理几百 MB 的日志或 CSV 文件时，一次性读进内存再转换，极易触发 OOM。正确做法是用 transform.NewReader / transform.NewWriter 包装原始 io.Reader 或 io.Writer，让转换发生在数据流动过程中。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 读 GBK 文件并解析 JSON：
json.NewDecoder(transform.NewReader(f, gbk.Decoder)) - 读 GBK CSV：
csv.NewReader(transform.NewReader(f, gbk.Decoder)) - 写 GBK 文件：
w := transform.NewWriter(f, gbk.Encoder); fmt.Fprint(w, "你好") - 注意：BOM 处理——GBK 无合法 BOM，若输入含
0xEF 0xBB 0xBF，需提前跳过前 3 字节，否则gbk.Decoder直接报错
容易被忽略的边界：BOM、不可映射字符、错误传播
实际对接老系统时，这三点最容易导致线上故障：
立即学习“go语言免费学习笔记（深入）”；
- Windows 记事本保存的 GBK 文件可能带 BOM（虽然不标准），
gbk.Decoder不吃这个，必须手动截断；建议封装一层skipBOM工具函数 - UTF-8 字符串含 emoji（
U+1F600）或古籍用字（U+3400类），gbk.Encoder.Bytes会返回 error，不能忽略——得明确设计 fallback 策略（如记录日志 + 替换为[?]） - 错误类型不是
io.EOF或os.PathError，而是*encoding.InvalidUnreadableError，用errors.As(err, &e)判断才可靠，直接err == nil容易漏判
