go语言不内置gbk等非utf-8编码支持，必须用golang.org/x/text/encoding显式转换；string([]byte)强转会乱码，正确做法是通过simplifiedchinese.gbk.newdecoder().bytes()解码或newencoder().bytes()编码，并注意复用、错误处理与流式内存控制。
Go 语言本身不内置 GBK、Big5、Shift-JIS 等非 UTF-8 字符集的编解码能力，直接用 string 或 []byte 强转会损坏中文——这不是“学不会”，而是设计使然。真正的高性能字符集转换，必须依赖 golang.org/x/text/encoding 及其子包，且需注意编码器复用、错误处理粒度和内存分配模式。
为什么不能用 []byte(str) 直接转 GBK
Go 的 string 恒为 UTF-8 编码字节序列。[]byte(str) 只是按字节拷贝，若原字符串含中文（如 "你好"），UTF-8 下占 6 字节；而 GBK 中仅占 4 字节，且字节含义完全不同。强行 reinterpret 会导致乱码或 panic。
- 现象：
string([]byte("你好"))输出正常，但string(gbkBytes)在 UTF-8 环境下显示 - 本质：UTF-8 和 GBK 是互不兼容的编码方案，不存在字节级一一映射
- 正确路径：先将 UTF-8
string解码为 Unicode 码点（[]rune），再编码为目标字符集字节
用 golang.org/x/text/encoding/simplifiedchinese 转 GBK
这是官方推荐、生产可用的方案，支持 GBK、GB18030、HZ-GB-2312 等简体中文编码。关键在于复用 Encoder 实例，避免每次新建带来的开销。
- 导入：
import "golang.org/x/text/encoding/simplifiedchinese" - 创建复用编码器：
gbkEnc := simplifiedchinese.GBK.NewEncoder()（全局或池化） - 转换字符串：
gbkBytes, err := transform.String(gbkEnc, utf8Str) - 转换字节切片：
gbkBytes, err := transform.Bytes(gbkEnc, utf8Bytes) - 注意：
transform.String返回新字符串对应的 GBK 字节，不是字符串；结果需用[]byte接收
性能敏感场景：避免 transform.String 的隐式内存分配
transform.String 内部会创建 strings.Builder 并调用 Write，对高频小字符串（如日志字段、协议头）有明显 GC 压力。此时应改用 transform.NewWriter 复用缓冲区。
- 预分配缓冲区：
var buf bytes.Buffer，清空后重复使用 - 绑定编码器：
w := transform.NewWriter(&buf, gbkEnc) - 写入：
w.Write([]byte(utf8Str))，然后gbkBytes := buf.Bytes() - 务必调用
buf.Reset()清空，否则下次写入会追加而非覆盖 - 对比：10 万次转换，复用
bytes.Buffer比transform.String减少约 35% 分配次数
Windows 下用 iconv_cgo 是权宜之计
虽可通过 cgo 调用 Windows iconv DLL 实现 GBK 转换，但引入 C 依赖会破坏 Go 的纯静态链接优势，且跨平台构建失败、调试困难、无法做竞态检测（-race 不支持 cgo）。
- 仅建议：遗留系统对接、已有 iconv.dll 部署环境、临时脚本
- 禁止用于微服务、CLI 工具、云原生组件等需要可移植性的场景
- 替代方案：坚持用
x/text/encoding，它已覆盖 99% 常见编码，包括encoding/japanese（Shift-JIS）、encoding/korean（EUC-KR）
真正容易被忽略的是错误处理粒度——transform 默认遇到非法 UTF-8 序列会返回 err != nil，但实际业务中常需“跳过坏字节”或“替换为 ?”。这时得传入自定义 html.EscapeString 类似策略的 transform.Nop 或 transform.Remove，而不是硬吞 panic。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
