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