os.ReadFile会panic是因为其内部调用io.ReadAll，强制一次性将整个文件加载到内存，2GB文件直接申请2GB堆空间，触发OOM kill；它仅适用于小文件（如配置、小JSON），几十MB就应警惕。
os.ReadFile 为什么一读就 panic
os.ReadFile 内部调用 io.ReadAll，强制一次性把整个文件 malloc 到内存。2GB 日志进来，进程立刻申请 2GB 堆空间——Go runtime 来不及 GC，系统直接 OOM kill。这不是 bug，是设计定位：它只适合配置、小 JSON 这类“全量加载即结束”的场景。
- 常见错误现象：
runtime: out of memory或直接被 OS 杀掉（Killed: 9） - 几十 MB 就该警惕：容器环境或嵌入式设备里，OOM 更敏感
- 别被
bufio.NewReader(file).ReadString('\n')欺骗——它底层仍可能缓存大量未消费数据，尤其遇到超长无换行字段时
bufio.Scanner 读超长行会 panic？怎么救
bufio.Scanner 默认单行缓冲上限是 64KB，遇到含 base64 的日志行或未换行的 JSON blob，scanner.Scan() 返回 true 后紧接着 scanner.Err() 就报 scanner: token too long。这个错误不会在 Scan() 里抛出，必须显式检查。
- 安全做法：
scanner.Buffer(make([]byte, 64*1024), 1024*1024)设最大长度为 1MB，别用math.MaxInt32 -
scanner.Text()返回的是当前缓冲区拷贝，安全；但若要字节操作（如跳过 BOM），改用scanner.Bytes()避免 string 转换开销 - 最后一行没换行符？
scanner.Scan()在 EOF 时仍会返回该行——前提是没触发缓冲溢出
io.CopyBuffer 比 io.Copy 必须显式用
io.Copy 默认用 32KB 缓冲，在本地磁盘尚可，但在 NFS、USB 盘或高延迟云盘上会频繁阻塞，吞吐暴跌甚至报 broken pipe。原因不是函数不行，是小块 write 导致 syscall 过多。
- 实测 NFS 上提速 3–5 倍；目标是 HTTP 响应体时也更稳
- 推荐缓冲大小：
64 * 1024到1024 * 1024（64KB–1MB）之间 - 别包一层
bufio.Reader——它的默认 4KB 缓冲只是预读，不改变内存模型，反而容易因Peek/UnreadByte导致 chunk 边界错位
写大文件为什么 w.Flush() 必须显式调用
bufio.NewWriter 是带缓冲的，不 Flush() 就关文件，数据大概率丢在用户态缓冲里没落盘——尤其在程序异常退出或 SIGKILL 场景下。
立即学习“go语言免费学习笔记（深入）”；
- 默认缓冲区仅 4KB，太小导致 syscall 过多；设太大（如 100MB）又失去流控意义，且错误暴露延迟
- 推荐：
bufio.NewWriterSize(f, 1<<20)（1MB），配合每批处理后w.Flush()，或在关键断点（如每百万条记录）强制刷盘 - 若需原子写入，先写临时文件再
os.Rename，避免写到一半崩溃留下脏数据
真正难的从来不是“怎么读”，而是块边界与业务逻辑的对齐——比如加密流要对齐 cipher block size，断点续传要记 offset，这些地方缓冲区再大也救不了逻辑层的偏移管理漏洞。
