用 bufio.Scanner 正确但默认配置易因超长行（>64KB）触发 bufio.ErrTooLong 而静默失败；安全做法是合理设置 Buffer 上限、显式拷贝行数据、及时释放引用，并在复杂场景改用 bufio.Reader。
直接说结论：用 bufio.Scanner 是对的，但默认配置在大文件场景下几乎必然出问题——不是因为文件大，而是因为某一行太长；真正不占内存的关键，是控制缓冲区大小 + 及时丢弃行引用 + 绝不全量加载。
为什么 scanner.Scan() 突然返回 false 却没报错
这不是 I/O 错误，也不是 EOF，大概率是触发了 bufio.ErrTooLong。默认缓冲区上限 64KB，只要某一行（比如嵌入的 base64、JSON blob、堆栈 trace）超过这个长度，scanner.Scan() 就返回 false，而 scanner.Err() 返回的就是这个错误。
常见误判：
- 以为文件读完了，其实卡在超长行上
- 只检查
scanner.Scan()的返回值，忽略后续必须调用scanner.Err()判断 - 看到 panic 报
makeslice: len out of range，其实是扩容参数写错了
怎么安全调大 scanner.Buffer() 上限
必须两个参数都给，且第一个切片容量不能小于第二个上限值，否则还是走默认 64KB。
推荐写法：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
buf := make([]byte, 64*1024); scanner.Buffer(buf, 1024*1024)→ 初始 64KB，上限 1MB - 不要写
scanner.Buffer(nil, 1024*1024)，nil会让内部 fallback 到默认值 - 上限别设超过 4MB，再大就该换方案了；
math.MaxInt32是理论极限，不是可用值 - 如果业务不确定行长（比如解析第三方日志），不如直接跳过 Scanner
什么时候该放弃 Scanner，改用 bufio.Reader
当你需要以下任意一项时，bufio.Scanner 就不是最佳选择：
- 要保留原始换行符（
\r\n不想被自动归一化） - 单行可能超几 MB，且需主动截断 + 打 warn 日志，而不是直接失败
- 分隔符不是
\n（比如按\x00、|或空行切分） - 需要精确控制每次读多少字节，或配合
io.LimitReader做防御性读取
这时用 bufio.NewReaderSize(file, 1024*1024) 配合 reader.ReadString('\n') 或 reader.ReadBytes('\n') 更可控。注意：ReadString 在 EOF 且没找到分隔符时会返回已读内容 + io.EOF，得先判断 len(line) > 0 再处理。
真正防 OOM 的三个实操点
光调大缓冲区不等于内存安全。容易被忽略的是：
-
scanner.Text()返回的是内部缓冲区引用，循环中直接存进[]string或 map，所有元素最终指向最后一行 —— 必须显式拷贝：string(scanner.Bytes())或append([]byte{}, scanner.Bytes()) - 每行处理完立刻让变量失效：
line = ""或作用域内不跨循环引用，否则 GC 无法及时回收 - 绝对不用
ioutil.ReadFile()或os.ReadFile()加载大文件，它们会把整个文件塞进内存
最稳的组合是：os.Open() + bufio.NewReaderSize(..., 1MB) + 流式处理 + 行级深拷贝（仅当真需要保留时）。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
