应优先检测BOM（如0xEF,0xBB,0xBF识别UTF-8），再用github.com/rainycape/mooncake自动探测或golang.org/x/text/encoding.GB18030.NewDecoder()等手动尝试解码，GB18030兼容GBK/GB2312且更稳妥。
如何判断文件实际编码类型
Go 本身不自带编码探测功能，直接用 os.ReadFile 读取含中文的文件却显示乱码，大概率是文件用了 GBK、GB2312 或 UTF-8-BOM 等非标准 UTF-8 编码。别猜，得靠库实测。
推荐用 github.com/rainycape/mooncake（轻量、无 CGO）或 golang.org/x/text/encoding 配合手动尝试。前者能自动识别 GB18030/GBK/UTF-8，后者需你预设候选编码并逐个 decode 测试是否成功。
- 优先试
encoding.GB18030.NewDecoder()：它兼容 GBK 和 GB2312，比单独试 GBK 更稳妥 - UTF-8 文件若带 BOM，
bytes.HasPrefix(data, []byte{0xEF, 0xBB, 0xBF})可快速确认 - 避免用正则或字符长度“估算”编码——中文在 GBK 占 2 字节，在 UTF-8 占 3 字节，但混合 ASCII 时根本不可靠
用 golang.org/x/text/encoding 转换 GBK 到 UTF-8
这是最常用也最易出错的环节：不是所有“GBK”都叫 encoding.GBK。官方 x/text 里只有 encoding.GB18030，而 GB18030 是 GBK 的超集，能正确解码所有 GBK 内容，且对纯 ASCII 兼容性更好。
别用已废弃的 github.com/axgle/mahonia，它不支持 Go Module 且无法处理部分 GBK 边界字符（如“〇”、“〆”）。
立即学习“go语言免费学习笔记（深入）”；
- 转换代码核心就三行：
decoder := encoding.GB18030.NewDecoder() data, err := decoder.Bytes(srcBytes) if err != nil { /* 处理非法字节，比如截断的 GBK 双字节 */ } - 如果原始文件是 GB2312，
GB18030同样适用；但如果是 Big5，就得换encoding.Big5 - 注意
decoder.String()和decoder.Bytes()行为一致，但前者会额外分配字符串头，小文件用Bytes更省内存
写回文件时要不要加 UTF-8 BOM
绝大多数现代工具（VS Code、GoLand、Linux 终端）不需要也不推荐 BOM。加了反而可能让 go build 报 illegal character U+FEFF 错误，尤其当 BOM 出现在 Go 源码开头时。
- 仅当明确对接老旧 Windows 工具（如某些 Excel 导入、旧版 Notepad）才考虑写 BOM
- 加 BOM 就是前置三个字节：
[]byte{0xEF, 0xBB, 0xBF}，拼接在 UTF-8 数据前即可 - 用
os.WriteFile写入时，BOM 必须在最开头，不能插在中间或末尾
批量处理时如何避免 panic 或静默失败
中文文件名 + 编码混杂 + 权限问题，很容易让 filepath.Walk 在某一层就崩掉。别让一个文件失败导致整个流程中断。
- 每个文件处理都包一层
defer func() { recover() }()不够——要捕获具体错误，记录路径和原因，继续下一个 - 对
io.ReadFull或decoder.Bytes()的错误，区分是“编码错误”还是“I/O 错误”：前者可跳过或转为替代字符（decoder.WithFallback(...)），后者应告警并停任务 - Windows 下路径含中文时，确保 Go 进程启动环境变量
GODEBUG=winutf8=1（Go 1.22+ 默认启用），否则os.Open可能返回no such file or directory即使路径完全正确
真正麻烦的从来不是“怎么转”，而是“哪个文件用了什么编码”“转完有没有丢字”“下次再读是不是又乱”。多打几行日志，比硬编码几个 encoding.XXX 更值得花时间。
