os.readfile 是 ioutil.readfile 的直接替代，仅需替换包名；go 1.16+ 已弃用 ioutil，编译报警，1.20+ 部分环境直接失败；二者签名、行为、返回值完全一致，但 os.readfile 性能略优且更安全。
os.ReadFile 就是 ioutil.ReadFile 的直接替代，不用改逻辑，只换包名
Go 1.16 起，ioutil.ReadFile 已被正式弃用，编译时会报警告；它所有行为、参数、返回值都原封不动迁移到了 os.ReadFile。这不是“升级版”，就是同一个函数搬了家。
-
os.ReadFile内部自动Open→ReadAll→Close，你不用管文件句柄 - 签名完全一致：
func ReadFile(name string) ([]byte, error)，替换ioutil为os即可 - 旧代码里还留着
"io/ioutil"导入？删掉，否则 lint 工具或 CI 可能直接报错 - 如果项目还在用 Go 1.15 或更早——别急着升级函数，但请尽快升级 Go 版本，因为
ioutil在后续版本中已被彻底移除（不是弃用）
为什么必须换？不只是“官方建议”，而是真实影响编译和维护
继续用 ioutil.ReadFile 不仅过时，还会在现代 Go 生态中引发实际问题：
- Go 1.20+ 的某些构建环境（如 Bazel、gopls v0.14+）已默认禁用
io/ioutil，直接编译失败 - 静态分析工具（如
staticcheck）会标记为SA1019：使用了已弃用的标识符 - 团队协作时，新人 clone 项目后
go mod tidy可能因依赖间接拉入旧版ioutil行为，导致本地行为与 CI 不一致 -
os.ReadFile比旧版少一层包转发调用，性能略优（微乎其微，但无损）
读大文件别硬套 os.ReadFile，OOM 不是吓唬人
os.ReadFile（以及当年的 ioutil.ReadFile）本质是把整个文件一次性读进内存，适合小文件；一旦文件超几十 MB，就可能触发 runtime: out of memory。
- 典型踩坑场景：用它读日志文件、导出 CSV、用户上传的 ZIP 元数据——这些看似“文本”，实则动辄百 MB
- 真正安全的做法是用
os.Open+bufio.Scanner（逐行）或io.Copy（流式复制） -
bufio.Scanner默认单行上限 64KB，超长行会返回scanner.ErrTooLong，别忽略这个错误 - 若需精确控制缓冲区大小（比如解析二进制协议头），直接用
io.ReadFull或bufio.NewReaderSize
写文件也同步迁移：os.WriteFile 替代 ioutil.WriteFile
读要换，写也得换——os.WriteFile 是 ioutil.WriteFile 的完全等价替代，连第三个权限参数 0644 的含义和平台表现都一模一样。
立即学习“go语言免费学习笔记（深入）”；
-
os.WriteFile默认行为是覆盖写入（O_TRUNC），不支持追加；想追加必须用os.OpenFile配合os.O_APPEND | os.O_WRONLY | os.O_CREATE - 权限参数在 Windows 上被忽略，但务必传（比如
0644），否则跨平台构建时可能被 linter 报警 - 注意：它不保证原子性写入（如先写临时文件再 rename），如需强原子性，得自己封装
- 测试时别用
os.WriteFile直接写固定路径；应改用os.CreateTemp创建隔离临时文件，避免并发冲突和残留
最常被忽略的一点：很多人以为“只是换个包名”，结果在旧项目里全局替换了函数名，却忘了删掉 "io/ioutil" 导入——这会导致未使用的导入（imported and not used）错误，而 Go 编译器对此零容忍。
