必须用golang.org/x/text/encoding/simplifiedchinese.gb18030显式转码：读gbk文件需先os.readfile得[]byte，再gb18030.newdecoder().bytes()解码为合法utf-8；写入时用gb18030.newencoder().string()或transform.newwriter流式处理，避免string强制转换和乱码。
Go 里字符串天然是 UTF-8，想转 GBK 或从 GBK 读出来，不能靠 string() 强转、也不能用 strings.ToValidUTF8 补救——那只是把乱码替换成 ，语义已丢。必须用 golang.org/x/text/encoding 显式做字节到字节的转换。
读 GBK 文件时 panic: invalid UTF-8 sequence 怎么办
这不是文件坏了，是 Go 运行时在某些操作（比如 json.Unmarshal、regexp.Compile）里偷偷校验 UTF-8 合法性，而你传进去的是 GBK 字节流。
- 别用
os.ReadFile后直接string(data)——这一步就埋了雷 - 先按
[]byte读出来，再交给simplifiedchinese.GB18030.NewDecoder().Bytes()解码，返回的是合法 UTF-8[]byte -
simplifiedchinese.GBK已被标记为 deprecated，优先用GB18030：它兼容所有 GBK 字符，且对生僻字、扩展区支持更稳 - 如果文件开头有 BOM（如
0xBF 0xBE），GB18030解码器能自动跳过；手动bytes.TrimPrefix反而可能切掉首字符
写 UTF-8 字符串到 GBK 文件却显示乱码
本质是你没做编码转换，只是把 UTF-8 字节原样写进了文件，而目标程序（比如老系统、Windows 记事本）按 GBK 解释这些字节，自然乱。
- 别用
f.WriteString(s)或fmt.Fprint(f, s)——它们写的是 UTF-8 字节 - 正确路径是：
simplifiedchinese.GB18030.NewEncoder().String(s)，或用transform.NewWriter(f, encoder)流式写入 - 大文件别一次性
encoder.Bytes([]byte(s))，容易 OOM；改用transform.NewWriter边写边转，内存恒定 -
transform.Writer遇到无法映射的字符（比如 emoji）默认返回 error，但io.Copy会静默停止——务必检查err
流式处理大文件避免 OOM
几百 MB 的日志或 CSV 文件，一次性加载再转码，两份字节（原始 + 转码后）同时驻留内存，很容易爆掉。
- 读 GBK → UTF-8：用
transform.NewReader(file, decoder)包裹*os.File，再传给csv.NewReader或json.NewDecoder - 写 UTF-8 → GBK：用
transform.NewWriter(file, encoder)，然后io.Copy或直接w.Write -
transform.NewReader返回的io.Reader不支持Seek，需要多次读就重开文件或分块处理 - 解码器和编码器实例不是 goroutine 安全的，别复用同一个实例处理并发请求
最易被忽略的一点：GBK 没有标准 BOM，但有些 Windows 工具会往开头硬塞 0xBF 0xBE；而 UTF-8 BOM 是 0xEF 0xBB 0xBF，写 UTF-8 文件时加它能让记事本等工具更可靠识别——但 GBK 文件加这个反而会出错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
