os.ReadFile读出乱码是因为它只返回原始字节流，不检测也不转换编码；需先用对应解码器（如simplifiedchinese.GBK.NewDecoder）将字节转为合法UTF-8字符串，再执行搜索等操作。
为什么 os.ReadFile 读出来全是乱码
因为 os.ReadFile 只返回原始字节流，不检测也不转换编码。你用它读 GBK、Shift-JIS 或 ISO-8859-1 文件，直接转成 string 就是乱码——这不是 Go 的 bug，是它压根没做这一步。常见表现包括：strings.Contains(content, "中文") 返回 false，json.Unmarshal 报 invalid character ''，终端打印一堆问号或方块。
优先检查 BOM，别跳过这 4 字节
BOM 是最可靠的编码线索，比内容采样早、准、快。UTF-8（EF BB BF）、UTF-16 LE（FF FE）、UTF-16 BE（FE FF）、UTF-32 LE（FF FE 00 00）、UTF-32 BE（00 00 FE FF）都藏在前 4 字节里。匹配到后必须跳过对应字节数，再把剩余内容交给解码器；没匹配到才走 fallback 推断逻辑。
-
golang.org/x/text/encoding/unicode提供UTF16和UTF8的NewDecoder()，可直接用于 BOM 分支 - Windows-1252、GBK、Big5 等编码本身不带 BOM，但 BOM 检测仍是第一道防线，不能省
- 别自己写 4 字节比对逻辑——用
bytes.HasPrefix+ 预定义字节切片更安全
fallback 用 charset.DetermineEncoding，不是 charset.NewReaderLabel
charset.NewReaderLabel 不是编码探测函数，它只做「已知 label 下的解码协商」，比如从 HTTP header 或 HTML meta 里提取 charset=gbk 后执行解码。它不会分析字节分布去猜编码，传错 label 还可能 panic。
- 真正做字节流启发式探测，得用
golang.org/x/net/html/charset的DetermineEncoding，它基于 Mozilla 算法，支持 ISO-8859-*、Windows-125x、GBK、Big5 - 它对短文本（
- 返回
nil表示无法判断，此时应 fallback 到unicode.UTF8，而不是 panic 或硬设 GBK - 注意：它不识别 Shift-JIS，若业务明确来自日文系统，需额外加一层
japanese.ShiftJIS.NewDecoder()尝试
封装 ReadTextFile 时，别漏掉字节流拼接和换行符兼容
把 BOM 检测、fallback 推断、解码器注入、逐行读取打包成一个函数，能避免每次重复样板逻辑。但容易被忽略的关键点是：
立即学习“go语言免费学习笔记（深入）”；
- 读完 BOM 后，要把「跳过的 BOM 字节」和「剩余文件内容」拼回完整字节流，再交给解码器——否则丢数据
- 别用
bufio.Scanner直接扫string，它内部按\n切分，遇到\r\n会把\r留在上一行末尾；应先解码为[]byte，再用bytes.Split或strings.Split处理 - 如果已知文件来源（如 Windows 记事本导出），可跳过探测，直接用
simplifiedchinese.GBK.NewDecoder()，性能更高也更稳
最麻烦的不是“怎么写”，而是某些编码根本没官方 encoder——比如 Shift-JIS 在 golang.org/x/text/encoding/japanese 里，Windows-1252 在 charmap 里，但有些东欧小众编码得自己实现 transform.Transformer。遇到这种，先确认是否真需要：很多所谓“Windows-1252 文件”，其实只是含 Latin-1 字符的 UTF-8，被错误声明罢了。
