Go默认不支持GBK编码，需用golang.org/x/text/encoding/simplifiedchinese.GBK显式解码；正确做法是用transform.NewReader包装文件读取器，严格校验err（尤其transform.ErrInvalidUTF8），避免字符串替换、后缀猜编码或ToValidUTF8补救。
为什么刚装完 Go 还是读不出 GBK 文件？
不是环境没搭好，而是 Go 本身不带任何非 UTF-8 编码支持——os.ReadFile 返回的 []byte 没问题，但直接 string(data) 就会乱码。这不是 bug，是设计：Go 的 string 类型语义上必须是合法 UTF-8 字节序列。
必须显式引入编码转换能力，且不能靠“猜编码”或字符串替换修复。
- 别用
strings.ReplaceAll手动替换中文字符：GBK 是双字节编码，单字节操作必然错位 - 别依赖文件后缀（如
.txt）判断编码：Windows 记事本存的 “ANSI” 文件大概率是 GBK，不是 UTF-8 - 别用
strings.ToValidUTF8补救：它只把非法 UTF-8 替换成，原始字节信息永久丢失
必须安装的包和 import 路径
官方推荐、生产可用的方案只有 golang.org/x/text/encoding 及其子包，其他如 mahonia 已多年未维护，且不处理 GBK 扩展区、造字区等边缘 case。
安装命令：
立即学习“go语言免费学习笔记（深入）”；
go get golang.org/x/text/encoding/simplifiedchinese
对应 import：
import "golang.org/x/text/encoding/simplifiedchinese"
注意：simplifiedchinese.GBK 是首选，不是 encoding/gbk（后者已弃用），也不要用 encoding/gb2312（不支持扩展汉字）。
-
simplifiedchinese.GBK支持 GBK 全集，含 GB18030 子集和兼容区 -
simplifiedchinese.GB18030可用于更严格的合规场景，但性能略低 - 不要同时 import 多个 encoding 包，除非真需要多编码切换
读取 GBK 文件转 UTF-8 string 的正确写法
核心是用 transform.NewReader 套一层解码器，而不是先读再转——否则容易触发 transform.ErrShortSrc 或内存越界。
示例代码片段（无错误忽略）：
file, err := os.Open("input.txt")
if err != nil {
return "", err
}
defer file.Close()
decoder := simplifiedchinese.GBK.NewDecoder()
reader := transform.NewReader(file, decoder)
data, err := io.ReadAll(reader)
if err != nil {
// 注意区分：transform.ErrInvalidUTF8 表示源数据含非法 GBK 字节（文件损坏或编码判错）
// 其他 err 如 io.EOF 属正常结束
return "", err
}
return string(data), nil
- 务必检查
err，尤其transform.ErrInvalidUTF8—— 它说明你指定的编码错了，不是程序写错了 - 别用
bufio.Scanner直接读：它内部按行切分，会在 GBK 双字节中间截断，导致后续解码失败 - 大文件建议用
io.Copy+io.Discard或流式处理，避免一次性加载进内存
高频小字符串转换时的性能陷阱
transform.String 看起来简洁，但在日志字段、HTTP header、协议解析等高频场景下，会因隐式创建 strings.Builder 和反复分配带来明显 GC 压力。
实测 10 万次转换，复用 bytes.Buffer 比 transform.String 减少约 35% 分配次数。
正确做法：
var buf bytes.Buffer gbkEnc := simplifiedchinese.GBK.NewEncoder() // 每次转换前重置缓冲区 buf.Reset() w := transform.NewWriter(&buf, gbkEnc) _, _ = w.Write([]byte(utf8Str)) gbkBytes := buf.Bytes()
- 必须调用
buf.Reset()，否则下次写入是追加而非覆盖 -
gbkEnc可全局复用，它是无状态的，新建开销小但没必要 - 如果目标是写文件，直接用
transform.NewWriter(file, encoder)更省内存
真正麻烦的从来不是“怎么写”，而是“怎么确保每次都不漏掉 Reset()”和“怎么验证源编码真就是 GBK”。这两点没盯住，后面所有优化都白搭。
