bufio.Scanner 是大文件按行处理的首选，因其内置安全边界（默认单行64KB上限）、自动换行符处理、固定缓冲区复用、内存占用恒定且不暴露原始字节切片；正确使用需避免长期持有 scanner.Text() 结果，改用 strings.Clone 或 string(scanner.Bytes()) 保存，务必检查 scanner.Err()，仅在需精确控制换行符或处理超长行时才换用 bufio.Reader.ReadLine()。
为什么 bufio.Scanner 是大文件按行处理的首选
因为 bufio.Scanner 内置了安全边界和缓冲管理，不会像 bufio.Reader.ReadLine() 那样把超长行直接拖垮内存。它默认单行上限 64KB，超出会返回 scanner.ErrTooLong，而不是 panic 或 OOM。这在解析日志、配置或用户上传文本时是关键防线。
- 它自动跳过
\r\n和\n换行符，无需手动 trim - 底层复用固定大小缓冲区（默认 4KB），内存占用恒定，与文件总行数无关
- 不暴露原始字节切片，避免意外的内存引用延长生命周期
- 比
ReadLine()少一层错误判断（不用区分isPrefix和err == nil）
如何正确使用 scanner 避免常见陷阱
错误写法是把 scanner.Text() 结果存进切片长期持有——这会间接持有整个底层缓冲区，导致内存无法释放。正确做法是只在当前迭代内使用该字符串，或显式拷贝。
- 不要写
lines = append(lines, scanner.Text())处理 GB 级日志——scanner.Text()返回的是缓冲区内子切片，所有行共享同一底层数组 - 需要保存内容时，改用
strings.Clone(scanner.Text())（Go 1.20+）或string(scanner.Bytes()) - 务必检查
scanner.Err()，而不仅是scanner.Scan() == false——EOF 是正常终止，但 I/O 错误（如磁盘断开）必须显式捕获 - 若需自定义分隔符（如按 JSON 对象分割），用
scanner.Split(bufio.ScanLines)替换为bufio.SplitFunc
什么时候该换用 bufio.Reader.ReadLine()
只有当你需要精确控制每行末尾是否保留 \n 或 \r\n，或者必须处理超过 64KB 的单行数据（如某些二进制嵌入文本）时，才考虑 bufio.Reader.ReadLine()。但它要求你手动处理 isPrefix 分段逻辑，容易出错。
-
ReadLine()返回[]byte，不是string，频繁转 string 有额外分配开销 - 它不自动限制单行长度，遇到畸形输入（如缺失换行符的超长行）会持续增长 slice，最终 OOM
- 必须自己拼接
isPrefix == true的多段数据，代码更冗长 - 如果只是想跳过空行或注释，
Scanner配合简单 if 判断更轻量
流式处理中关闭文件和资源的顺序很关键
用 defer file.Close() 放在 os.Open() 后面看似稳妥，但在循环中启动多个 goroutine 处理不同文件时，它会在函数退出才触发，可能早于 scanner 完成读取——尤其当 scanner 缓冲未刷完、或底层 file.Read() 调用被阻塞时。
立即学习“go语言免费学习笔记（深入）”；
- 推荐结构：打开文件 → 创建 scanner → defer scanner 的 close（如果封装了）→ 显式在 for 循环结束后 close file
- 若封装成函数，用
defer file.Close()是安全的；但若传入已打开的*os.File给其他 goroutine，关闭责任必须明确归属一方 - 别依赖
runtime.GC()强制回收——文件句柄是系统资源，不 close 可能快速耗尽 ulimit - 临时文件场景下，还要记得
os.RemoveTemp或os.RemoveAll清理残留
