Go标准库只支持UTF-8，GBK字节切片强转string会产生乱码和json.Marshal错误；必须用golang.org/x/text/encoding先解码为UTF-8 string再处理。
为什么 gob 或 json.Marshal 无法直接处理 GBK 字符串
Go 标准库默认只认 UTF-8。一旦遇到 GBK 编码的字节切片（比如从旧系统读取的文件或 socket 数据），string(data) 强转后会产生乱码，后续 json.Marshal 会因含非法 UTF-8 序列而返回错误 json: invalid UTF-8 in string。这不是“编码没选对”，而是 Go 的 string 类型语义强制要求底层字节是合法 UTF-8 —— 它不支持“字符串即字节容器”这种宽松模型。
所以不能绕过解码环节直接操作；必须先用正确字符集解码为 string，再按需重新编码。
用 golang.org/x/text/encoding 实现 GBK ↔ UTF-8 转换
官方扩展包 x/text/encoding 提供了生产级、带错误策略的编码器。它不是简单查表，而是处理了 GBK 中的兼容区、造字区、以及各种边缘 case（比如未定义码位）。
- 安装：
go get golang.org/x/text/encoding - 常用编码器：
encoding/gbk（对应 GBK）、encoding/simplifiedchinese（含 GB18030、GB2312 等） - 转换时建议显式指定错误策略：
unicode.ReplaceUnknown（替换成 ）或unicode.Strict（遇到非法序列直接报错）
示例：将 GBK 字节转 UTF-8 string
立即学习“go语言免费学习笔记（深入）”；
import (
"golang.org/x/text/encoding/simplifiedchinese"
"golang.org/x/text/transform"
"io"
)
func gbkToUTF8(b []byte) (string, error) {
reader := transform.NewReader(bytes.NewReader(b), simplifiedchinese.GBK.NewDecoder())
out, err := io.ReadAll(reader)
if err != nil {
return "", err
}
return string(out), nil
}
自定义 JSON marshal/unmarshal 以透明支持 GBK 字段
如果结构体字段原始数据是 GBK 编码的 []byte，但业务逻辑需要当 string 用，又得保证 JSON 输出是合法 UTF-8，最稳妥的方式是实现 UnmarshalJSON 和 MarshalJSON 方法。
- 反序列化时：先按原样读成
[]byte，再用 GBK 解码器转成string - 序列化时：把
string用 GBK 编码器转回[]byte，再 JSON 编码为字符串（注意：不是直接json.Marshal(s)，那会误把 UTF-8 当 GBK 处理） - 别在
UnmarshalJSON里用json.Unmarshal递归解析——容易栈溢出或死循环
关键点：编码器必须复用，避免每次调用都新建状态对象（GBK.NewEncoder() 是轻量的，但频繁创建仍影响 GC）
性能与内存注意事项
GBK 到 UTF-8 的转换不是零成本操作。实测单次 1KB 数据约耗时 1–3μs，但若高频调用（如日志字段、HTTP 响应体），累积开销明显。
- 避免在 hot path 上反复转换同一段数据；可缓存 UTF-8 版本（加
utf8Cache string字段 + 懒加载标记） -
transform.NewReader会分配临时 buffer，大量小数据建议用transform.String替代io.ReadAll减少 alloc - GB18030 编码器比 GBK 更重（支持更多汉字），若确定只用 GBK，别误用
simplifiedchinese.GB18030
真正容易被忽略的是错误策略选择：用 Strict 时，一个损坏的 GBK 字节（比如 0xA1A1 在某些老设备上可能越界）会导致整个请求失败；而 ReplaceUnknown 虽安全，但会掩盖数据质量问题 —— 这得结合上游数据可信度来权衡。
