应使用流式处理替代 io.readall：优先用 bufio.scanner 处理文本日志，超长行或二进制则用 bufio.newreader 配合自定义缓冲区读取；结构化解析选 encoding/csv.reader 或 json.decoder；io.copy 也需显式指定缓冲区避免内存激增。
Go 读大文件时 io.ReadAll 触发 OOM 怎么办
直接用 io.ReadAll 读几 GB 的日志或导出文件，进程大概率被系统 kill —— 它会把整个文件一股脑塞进内存，不看文件大小也不打招呼。
真正该用的是流式处理：边读边处理，不缓存全文。核心是放弃「一次性加载」思维，改用 bufio.Scanner 或 bufio.Reader 分块推进。
-
bufio.Scanner默认每行上限 64KB，超限直接报scanner.ErrTooLong，适合文本日志但不适用于超长行或二进制 - 需要完全控制分块大小（比如每次读 1MB），就绕过
Scanner，用bufio.NewReader+Read或ReadSlice - 如果必须结构化解析（如 CSV/JSON 行），优先选
encoding/csv.Reader或json.Decoder，它们内部已做流式解码，不会把整文件当字符串载入
为什么 os.Open + io.Copy 有时也爆内存
看起来很安全的复制操作，比如把大文件从 A 拷到 B，也可能吃光内存——问题出在默认的 io.Copy 缓冲区大小（io.DefaultBufSize = 32KB）太小，导致系统调用频繁，而某些底层实现（尤其 Windows 上的 CopyFile 重定向）可能意外缓冲更多数据。
更稳的做法是显式控制缓冲区，并避免中间落盘环节引入额外拷贝。
立即学习“go语言免费学习笔记（深入）”；
- 用
io.CopyBuffer(dst, src, make([]byte, 1 固定 1MB 缓冲，减少 syscall 次数且内存可控 - 若目标是压缩或加密后写入，别链式套
gzip.Writer+io.Copy，而应直接从os.File读、经gzip.Writer写入目标文件，避免中间[]byte缓存 - 注意
io.Copy不会自动关闭dst，漏关文件句柄会导致后续open too many files错误，和内存无关但常一起出现
defer file.Close() 在大文件循环里埋了什么雷
逐个打开几百个大文件做分析时，写 defer file.Close() 看似稳妥，实则会让文件句柄延迟到函数返回才释放——而 Go 的 goroutine 栈默认只有 2KB，大量 defer 记录堆积会先撑爆栈，报 runtime: goroutine stack exceeds 1000000000-byte limit，比内存溢出还早触发。
这不是 defer 本身的问题，是它用错了场景。
- 循环内必须立即关文件：用
file.Close()后接if err != nil { ... }，别 defer - 如果逻辑复杂想保 defer，就把单次文件处理抽成独立函数，让 defer 在子函数退出时生效
- 检查句柄数：Linux 下用
lsof -p $(pidof yourapp)，超过 1024 基本就是没及时关
错误处理中忽略 err 导致的静默内存泄漏
最隐蔽的溢出不是分配太多，而是该释放没释放。比如 json.NewDecoder(file).Decode(&v) 返回 io.EOF 是正常结束，但有人写成 if err != nil { return err }，结果 EOF 被当成错误提前返回，file 没关，下一轮循环又开新文件——句柄和底层 buffer 全堆积着。
Go 的错误不是布尔开关，得分类响应。
- 对
io.EOF和io.ErrUnexpectedEOF要单独判断，通常是流程终点，不是异常 - 网络或磁盘临时错误（如
syscall.EAGAIN）应重试，而非立即返回导致资源滞留 - 用
errors.Is(err, io.EOF)判断，别用==，因为底层错误可能是包装过的
大文件场景下，错误类型决定资源生命周期，漏判一个 EOF 就可能让整个批处理慢慢卡死。
