go读文件遇乱码大概率是bom问题，需用bytes.trimprefix(data, []byte("\xef\xbb\xbf"))显式去除utf-8 bom，否则json解析、字符串匹配等均会失败。
Go 读文件时遇到
UTF-8 文件开头出现 \xef\xbb\xbf（即 BOM）时，Go 的 io.ReadAll 或 bufio.Scanner 不会自动剥离它，后续字符串比较、JSON 解析、正则匹配都可能失败——比如 strings.HasPrefix(s, "{") 返回 false，因为实际开头是 \xef\xbb\xbf{。
bytes.TrimPrefix 是最轻量、最可控的去除方式
别用正则或手动切片，直接用标准库函数处理。BOM 是固定 3 字节前缀，bytes.TrimPrefix 安全、无副作用、不分配新底层数组（如果不需要裁剪则零拷贝）。
常见使用场景：
- 读取配置文件（如
config.json）后立即去 BOM，再传给json.Unmarshal - HTTP 响应体（
resp.Body）读出的[]byte在解析前清理 - 从
os.ReadFile得到原始字节，需转string前处理
示例：
data, _ := os.ReadFile("file.json")
data = bytes.TrimPrefix(data, []byte("\xef\xbb\xbf"))
var v map[string]interface{}
json.Unmarshal(data, &v) // 不再因 BOM 报错 invalid character '' looking for beginning of value
用 strings.Reader 或 bytes.NewReader 时，BOM 仍需手动处理
很多人以为包装成 Reader 就能“自动过滤”，其实不会。BOM 还在底层字节流里，所有后续读取操作（bufio.Scanner.Text()、json.NewDecoder().Decode()）都照常看到它。
关键点：
-
json.Decoder不识别 BOM，也不跳过——它严格按 RFC 7159 解析，开头必须是{或[ -
bufio.Scanner的Scan()返回的每行内容，若源文件首行带 BOM，则第一行的Text()仍含\xef\xbb\xbf - 如果用
strings.NewReader(string(data))，BOM 已变成 runeU+FEFF，但 JSON 解析器仍不认它
生产环境建议：封装一个带 BOM 检查的读取函数
反复写 bytes.TrimPrefix 容易遗漏。更稳妥的做法是统一入口处理，尤其当项目要支持 Windows 编辑器保存的 UTF-8 文件时。
可这样封装：
func ReadFileWithoutBOM(filename string) ([]byte, error) {
data, err := os.ReadFile(filename)
if err != nil {
return nil, err
}
if len(data) >= 3 && bytes.Equal(data[:3], []byte("\xef\xbb\xbf")) {
data = data[3:]
}
return data, nil
}
注意点：
- 不要用
utf8.RuneCount或strings.TrimSpace处理 BOM——前者对\xef\xbb\xbf计为 1 个 rune，后者完全无效 - 如果文件可能含 UTF-16/32 BOM（
\xff\xfe、\xfe\xff、\xff\xfe\x00\x00），需额外判断，但 Go 原生string只支持 UTF-8，这类文件应先转码 - HTTP 请求头若声明
Content-Type: text/plain; charset=utf-8，不代表响应体没 BOM——BOM 是字节层问题，跟 header 无关
BOM 不是编码错误，但 Go 的生态默认不兼容它；处理逻辑必须显式插入在「读取」和「解析」之间，漏掉一次，就可能卡住整个 pipeline。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
