os.ReadFile 是 Go 1.16+ 的标准推荐，ioutil.ReadFile 已弃用且在 Go 1.22+ 中移除；它封装了 os.Open、io.ReadAll 和 file.Close，一行读取小文件，安全简洁。
Go 读写文件没有“唯一正确方式”，只有“当前场景下最不踩坑的选择”。选错方式轻则性能差、内存爆，重则丢数据、权限错、文件残留句柄——尤其在生产环境跑着大日志或配置热加载时，问题会集中爆发。
os.ReadFile 和 ioutil.ReadFile 哪个该用？
直接结论：os.ReadFile 是 Go 1.16+ 的标准推荐，ioutil.ReadFile 已被弃用（deprecated），编译会警告，且在 Go 1.22+ 中彻底移除。
-
os.ReadFile内部封装了os.Open+io.ReadAll+file.Close，一行搞定，适合小文件（ - 它默认以
O_RDONLY打开，不支持自定义权限或 flag，强行传路径外参数会编译失败； - 若你还在用
ioutil.ReadFile，升级后必须替换，否则 CI/CD 流水线可能直接 fail； - 错误类型一致，都是
*os.PathError，但ioutil的包路径是io/ioutil（注意斜杠方向），容易和io包混淆。
大文件逐行读取为什么不能只用 os.Open？
os.Open 返回的是裸 *os.File，它实现了 io.Reader，但**没有缓冲**。直接拿它配 bufio.Scanner 或 bufio.Reader 没问题，但若跳过 bufio 自己循环调 file.Read，会频繁 syscall，性能极差。
- 常见错误：用
file.Read(buf)每次只读 1 字节，或 buffer 太小（如make([]byte, 1)），导致百万行日志读取慢 5–10 倍； -
bufio.Scanner默认每行上限 64KB，超长行会报scanner.ErrTooLong，需提前调scanner.Buffer(make([]byte, 64*1024), 1 扩容； - 若需保留换行符（
scanner.Text()去掉了\n），改用scanner.Bytes()； -
os.Open打开后必须defer file.Close()，漏掉会导致 fd 耗尽，Linux 下常见报错：too many open files。
os.OpenFile 的 flag 和 perm 参数怎么配才不出错？
os.OpenFile 是读写控制的“开关面板”，flag 决定能不能写、从哪写，perm 决定新文件的权限——这两者错一个，WriteString 就静默失败或 panic。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- flag 组合要按需选，常见组合：
os.O_CREATE | os.O_WRONLY | os.O_APPEND（追加）、os.O_CREATE | os.O_WRONLY | os.O_TRUNC（覆盖）； -
os.O_RDONLY下调file.WriteString会返回bad file descriptor错误，但不会 panic； - perm 权限只在文件**新建时生效**，已存在文件的权限不受影响；
0644表示 owner 可读写、group/others 只读，Linux 下安全，Windows 忽略； - Windows 上若用
0777，实际权限会被系统截断，建议统一用0644或0600（仅 owner）。
bufio.Writer 为什么必须 Flush？
bufio.Writer 是内存缓冲，不 Flush() 就等于“写了但没提交”——程序退出、panic 或 GC 触发前，数据可能还卡在 buffer 里，磁盘上啥也没有。
- 典型误用：
defer writer.Flush()放在os.OpenFile后，但文件句柄先 close 了，Flush()会报write: bad file descriptor； - 正确顺序：打开文件 → 创建
bufio.Writer→ 写入 →writer.Flush()→file.Close()； - 如果写入量不大（比如每次 os.WriteFile 更简单安全；
- 高频小写（如 metrics 打点），可复用
bufio.Writer实例并定期Flush()，避免反复 malloc buffer。
真正容易被忽略的不是语法，而是“谁负责关文件”“buffer 是否清空”“权限是否随平台生效”——这些点在本地测试永远 OK，一上容器或高并发就露馅。
