bufio.scanner 默认单行上限64kb，超长会panic；应显式调大缓冲区或改用bufio.reader+readstring控制内存，及时释放行引用防oom，避免全存切片，json解析优选json.newdecoder。
用 bufio.Scanner 读大文件，但别碰默认缓冲区
默认的 bufio.Scanner 只能处理单行 ≤ 64KB 的文本，超长就直接 panic：scanner: token too long。这不是 bug，是设计限制——它把整行先塞进内存再切分。
真实场景里，日志、CSV 或导出数据常有超长字段或无换行的巨型 JSON 行，直接用会崩。
- 必须显式调大缓冲区：
scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)（第二参数是最大令牌长度） - 更稳妥的做法是改用
bufio.Reader+ReadString('\n')，自己控制每次读多少、怎么截断 - 注意：增大缓冲区不等于“无限吃内存”，它只是允许单行更长；真正防 OOM 要靠流式处理+及时丢弃已处理行引用
用 bufio.Reader + ReadString 控制内存峰值
bufio.Reader 比 Scanner 更底层，适合对内存敏感或需自定义行边界（比如按 \r\n 或空行分割）的场景。
关键不是“读得快”，而是“读完一行立刻 GC 掉那行字符串”。Go 的 GC 不会立刻回收，所以别让上一行变量还被闭包、map 或全局 slice 引用着。
立即学习“go语言免费学习笔记（深入）”；
- 每行处理完立刻赋值为
line = ""，或用runtime.GC()强制触发（仅调试用） - 避免把所有行存进
[]string，哪怕只是临时做去重——改用map[string]struct{}并边读边删 - 如果行内要解析 JSON，用
json.NewDecoder(strings.NewReader(line)).Decode(&v)，别用json.Unmarshal([]byte(line), &v)，后者会额外复制一次字节切片
文件打开时加 os.O_RDONLY | os.O_DIRECT 未必有用
很多人看到“大文件”就想加 O_DIRECT 绕过页缓存，但 Go 的 os.File 在 Linux 下其实不支持该 flag（会静默忽略），且 bufio.Reader 本身已做了用户态缓冲，硬上 O_DIRECT 反而可能降低吞吐。
真正影响性能的是系统页缓存是否命中，以及磁盘 I/O 调度策略。对顺序读的大文件，Linux 的预读（readahead）通常比手动控制更高效。
- 优先调优
bufio.Reader缓冲大小（比如bufio.NewReaderSize(f, 1 即 1MB） - 确认磁盘类型：SSD 上预读收益小，HDD 上保持默认即可
- 用
lsof -p PID看进程实际内存占用，别只信top的 RES——Go runtime 的堆统计更准
遇到 invalid memory address or nil pointer dereference 怎么快速定位
这类 panic 多半不是读文件本身出错，而是你对某一行做了非空检查缺失，比如 strings.Split(line, "|")[3] 时 line 是空或字段不足。
尤其在管道处理中（如 cat big.log | go run main.go），os.Stdin 的 EOF 行为和文件略有差异，容易漏掉最后一行的边界判断。
- 永远在切片访问前检查
len(fields) > 3，别依赖文档说“格式固定” - 用
if line == "" || strings.TrimSpace(line) == "" { continue }过滤空行，防止后续解析崩溃 - 加一行
log.Printf("line %d: %q", i, line)打印前 100 字符，比看 panic 栈更快定位坏数据位置
strings.ReplaceAll 或正则匹配。这些函数内部会分配新字符串，累积起来比读取本身更吃内存。留个心眼，别光盯着 os.Open。 
