os.readfile仅适用于≤10mb小文件场景，因其一次性全量加载内存易oom；大文件或需流式处理时必须用os.open+bufio.reader/io.copy等流式方式，否则将直接触发runtime: out of memory。
小文件直接用 os.ReadFile 和 os.WriteFile，大文件或需控制读写节奏的场景必须流式处理——这不是风格选择，是内存安全和稳定性的硬性分界。
什么时候该用 os.ReadFile 而不是手动 os.Open/os.Close
90% 的配置加载、单次 JSON/YAML 解析、临时数据存取都适用。它自动完成打开 → 读取 → 关闭全流程，不漏关句柄，也不需要写 defer f.Close()。
-
os.ReadFile返回的是[]byte，要当字符串用得显式转：string(data)；它不校验 UTF-8 合法性 - 错误必须检查：返回
"no such file or directory"或"permission denied"时不处理，后续操作大概率 panic - 权限位（如
0644）只在创建新文件时生效，Windows 上基本忽略；设成0会导致 Linux/macOS 下文件不可读 -
os.WriteFile总是覆盖写，要追加？换os.OpenFile+os.O_APPEND
几十 MB 就不该用 os.ReadFile 的真实原因
它把整个文件一次性加载进内存，没流控、无缓冲区调节能力。几十 MB 就可能触发 runtime: out of memory，尤其在低内存容器或嵌入式环境里更敏感。
- 日志分析、GB 级备份、边读边解密/压缩等场景，必须流式处理
-
bufio.Scanner默认单行上限 64KB，超长行会报scanner.ErrTooLong；调大上限前先确认是否真需要——很多“超长行”其实是日志格式错误 -
io.Copy内部用 32KB 缓冲区，适合整块搬运（比如复制视频、保存 HTTP 响应体），不用手写循环读写逻辑
os.OpenFile 的 flag 组合决定实际行为
os.OpenFile 是底层统一入口，os.Open、os.Create 都是它的封装。真正控制“能不能写”“找不到是否创建”“是否清空”“是否追加”的，就是 flag 参数。
- 追加写（常用日志）：
os.O_WRONLY | os.O_APPEND | os.O_CREATE - 覆盖写（清空后重写）：
os.O_WRONLY | os.O_CREATE | os.O_TRUNC - 权限位（如
0644）仅在创建新文件时起作用，已存在文件的权限不会被修改 - 忘记
defer f.Close()是高频事故：Linux 下默认最多 1024 个打开文件，跑久直接卡死在too many open files；哪怕用了defer，也要注意它在函数return后才执行——中间 panic 且没recover，仍可能漏关
别在循环里反复调用 os.Open + os.WriteFile 处理多行
每轮都开闭文件，I/O 开销爆炸，还会快速耗尽文件描述符。
- 用
bufio.Scanner逐行读时，scanner.Text()返回拷贝，scanner.Bytes()返回切片引用——后者更快但生命周期受scanner控 - 想边读边过滤、转换、聚合？用
bufio.Scanner+ 自定义SplitFunc，但别自己写正则分割——性能差且容易出错 -
ioutil已在 Go 1.16+ 彻底移除，继续用会编译失败；所有旧代码必须迁移到os.ReadFile/os.WriteFile或io/bufio流式接口
最易被忽略的点：os.ReadFile 看似简单，但它对路径、权限、编码、错误处理全是“零容忍”；而流式处理看似复杂，其实只要选对接口（io.Copy vs bufio.Scanner）并守住 buffer 生命周期，反而更可控。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
