os.ReadFile仅读取原始字节，不解析任何Go值；需配合json.Unmarshal等手动解码，且必须处理error和context，大文件应改用流式读取。
ReadFile 读取的是字节，不是 Go 值
os.ReadFile 返回 []byte 和 error，它不解析、不解码、不反序列化。哪怕你读的是 config.json 或 data.go，它也只当一堆原始字节处理。想得到结构体、map 或 int，必须自己后续转换。
常见错误现象：
直接把 os.ReadFile("config.json") 的结果赋给 map[string]interface{} 变量，编译报错或 panic；或者用 fmt.Println 打印出一串乱码（其实是 UTF-8 字节流的默认字符串表示）。
- 使用场景：适合读取配置文件、模板文本、证书内容、嵌入的静态资源等“不需要即时结构化解析”的原始数据
- 若需结构化数据，必须配合
json.Unmarshal、toml.Decode、gob.NewDecoder等进一步处理 - 注意编码：Go 源文件默认 UTF-8，但
os.ReadFile不校验，如果文件是 GBK 编码，读出来就是乱码字节，需先转码
封装 ReadFile 时别漏掉 error 处理和 context 支持
简单封装成 ReadFileToString 或 ReadJSON 很常见，但容易忽略两点：一是错误未透传或被静默吞掉，二是无法响应超时或取消。
比如这个写法就有问题：
立即学习“go语言免费学习笔记（深入）”；
func ReadConfig(path string) map[string]interface{} {
data, _ := os.ReadFile(path) // ❌ 忽略 error
var cfg map[string]interface{}
json.Unmarshal(data, &cfg) // ❌ 错误没检查，data 可能为空
return cfg
}
推荐做法：
- 始终返回
error，调用方决定如何处理（重试、降级、panic） - 加
context.Context参数，尤其在服务中读取远程挂载配置（如 NFS）或大文件时，避免 goroutine 卡死 - 对 JSON/TOML/YAML 封装，应统一返回解码后的值 + error，不要返回
[]byte再让调用方解码
读取 Go 源码文件要小心 import 路径和 go:embed
如果你的目的是“读取另一个 Go 文件的内容用于分析或生成代码”，os.ReadFile 能用，但要注意路径是运行时相对路径（基于 os.Getwd()），不是编译时包路径。硬编码 "./internal/config/config.go" 在不同工作目录下会失败。
更可靠的方式是：
- 用
//go:embed配合embed.FS—— 编译期打包，路径安全，无 IO 开销 - 用
runtime/debug.ReadBuildInfo()或debug.BuildInfo获取模块信息，辅助构造路径 - 避免在生产环境动态读取
.go文件——这属于元编程范畴，易出错且难调试
例如用 embed 安全读取内嵌模板：
import "embed"
//go:embed templates/*.tmpl
var templatesFS embed.FS
func LoadTemplate(name string) ([]byte, error) {
return templatesFS.ReadFile("templates/" + name)
}
大文件别用 ReadFile，改用流式读取
os.ReadFile 把整个文件一次性加载进内存，对几百 MB 的日志或二进制资源极易触发 OOM。它的内部实现就是 os.Open + io.ReadAll，没有缓冲控制。
当文件大小不确定或可能超过几 MB 时，应切换为流式处理：
- 用
os.Open得到*os.File，再套bufio.NewReader或csv.NewReader等按需读取 - 对 JSON，用
json.Decoder直接解码io.Reader，无需全部载入 - 若仍想“封装成一个函数”，可接受
io.Reader而非string路径，提升复用性（支持文件、网络响应、bytes.Buffer）
容易被忽略的一点：即使你封装了 ReadFileJSON，如果底层还是调 os.ReadFile，那它就不是“适合大文件”的方案——名字会误导人。
