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