所谓“二进制乱码的配置文件”，99%是编码不匹配导致的字节流误读，不是真乱码；encoding/binary不适用文本解码，它仅处理结构化二进制协议。
直接说结论：所谓“二进制乱码的配置文件”，99% 是编码不匹配导致的字节流误读，不是真乱码；encoding/binary 不该用在这里，它只处理结构化二进制协议，不负责文本解码。
为什么 config 文件读出来像二进制乱码
常见现象是打开文件后看到 、\xef\xbb\xbf 或一串不可见控制字符。这不是 Go 的 bug，而是你用 UTF-8 解码器去读 GBK 编码的文件，或反过来——比如 Windows 上用记事本保存的配置文件默认是 GBK（代码页 936），而 Go 默认按 UTF-8 解析字符串字面量或 io.ReadAll 结果。
关键点：
-
os.ReadFile返回的是原始字节，不做任何编码转换 -
string(b)只是把字节序列强行解释为 UTF-8，若源非 UTF-8，结果必乱 - BOM（
\xef\xbb\xbf）在 Go 中无意义，反而干扰解析，应提前剥离
读取非 UTF-8 配置文件的正确姿势
别猜编码，显式声明并转换。用 golang.org/x/text/encoding/simplifiedchinese 处理 GBK/GB18030，用 golang.org/x/text/encoding/japanese 处理 Shift-JIS 等。
立即学习“go语言免费学习笔记（深入）”；
示例：读 GBK 配置并转 UTF-8 字符串
file, _ := os.Open("config.ini")
defer file.Close()
reader := transform.NewReader(file, simplifiedchinese.GB18030.NewDecoder())
content, _ := io.ReadAll(reader)
// 此时 content 是合法 UTF-8 字节，可安全 string(content) 或传给 ini/yaml 解析器
注意：
- 不要先
io.ReadAll(file)再转换——大文件会爆内存，必须流式转换 - 避免用
bufio.ReadString('\n')，它不识别编码，只按字节切分 - 若配置文件含 BOM，
transform.NewReader通常能自动跳过；若不行，手动检查前 3 字节并截断
解析阶段仍报错？检查协议层是否混入二进制字段
有些“配置文件”实际是混合格式：头部是文本（INI/YAML），但某段值是 base64 编码的二进制 blob，或直接嵌了加密密钥字节。这时乱码不是编码问题，而是你把 base64 字段当纯文本解析了。
典型错误：
- 用
ini.Load读取后，直接对某个 value 调string([]byte(v))—— 若该 value 是 base64 密钥，结果就是乱码 - YAML 解析器把
key: !!binary gIGB当字符串返回，你没调base64.StdEncoding.DecodeString就打印
正确做法：
- 确认配置格式规范（如 YAML spec 明确支持
!!binarytag），用支持该特性的解析器（如gopkg.in/yaml.v3） - 对已知是二进制的字段，走
base64或hex解码路径，而非强制转string - 若字段是原始字节（如 TLS 证书 PEM 块），保留为
[]byte，别碰string()
别让 encoding/binary 背锅
encoding/binary 的 Read 和 Write 完全不处理文本编码，它只认字节序和固定大小类型。如果你试图用它解析 INI 文件，会立刻 panic：invalid type string。它也不关心 BOM、换行符、空格——这些全是文本解析器的事。
真正需要 encoding/binary 的场景只有一个：配置文件本身就是二进制协议（比如 Windows 注册表 hive、SQLite WAL header、自定义打包格式），且你明确知道每个 offset 上是什么类型和字节序。否则，一律交给 ini、yaml、toml 等文本解析库 + 编码转换层。
最容易被忽略的一点：终端输出乱码和文件读取乱码是两件事。即使你正确读出了 UTF-8 字符串，Windows CMD 仍可能因 chcp 936 把它当 GBK 解——此时问题出在输出端，和读取逻辑无关。
