这是因为scanner.Text()返回同一内存地址，循环中未拷贝导致所有元素指向最后一行；需用string(scanner.Bytes())或显式拷贝，且须检查scanner.Err()及处理ErrTooLong。
用 bufio.Scanner 读文件，为什么有时只打印最后一行？
这不是 Scanner 的 bug，而是变量复用导致的典型误用：每次调用 scanner.Text() 返回的是内部缓冲区的同一块内存引用，如果在循环里把 line 直接存进 slice 或 map 而没拷贝，后续 Scan() 会覆盖它。
- 错误写法：
lines = append(lines, scanner.Text())→ 所有元素最终指向最后一行内容 - 安全写法：
lines = append(lines, string(scanner.Bytes()))或lines = append(lines, scanner.Text())（仅当不跨循环生命周期保存时才真正安全） - 真正要长期保留某行？必须显式拷贝：
fullLine := append([]byte{}, scanner.Bytes()...) - 检查错误不能只看循环是否退出——
scanner.Err()必须在循环后单独判断，否则 I/O 错误（如磁盘满、权限拒绝）会被静默吞掉
scanner.Scan() 突然返回 false，但没报错也没到文件尾？
大概率是单行超长触发了默认 64KB 限制，此时 scanner.Err() 会返回 bufio.ErrTooLong，而不是 io.EOF 或其他 I/O 错误。
- 不要直接 panic 或忽略——这是设计行为，不是异常
- 扩容缓冲区：在
NewScanner后立刻调用scanner.Buffer(buf, maxLen)，其中maxLen必须 ≥ 底层buf切片长度 - 示例：
buf := make([]byte, 128*1024); scanner.Buffer(buf, 128*1024)→ 支持最长 128KB 行 - 设太大（如 10MB）会导致大文件下内存飙升；设太小则仍会 panic；不确定行长时，优先考虑改用
bufio.Reader.ReadLine()
需要保留换行符、处理 Windows 换行或解析二进制分隔符？别硬撑 Scanner
Scanner 默认剥离 \n、\r\n、\r，且不暴露原始字节边界。一旦需求超出“纯文本去换行”，它就不再是最佳选择。
- 要保留
\n？用reader.ReadString('\n')，返回字符串含终止符，可用strings.TrimSuffix(line, "\n")按需清理 - 要兼容
\r\n且保留原样？reader.ReadBytes('\n')更稳，返回[]byte，你自己决定是否 trim\r - 按
\x00或其他非文本分隔符切分？reader.ReadBytes(0)或reader.ReadBytes('\t')是正解 - 注意：
ReadString在 EOF 且未找到分隔符时，会返回已读内容 +io.EOF，需先检查len(line) > 0再处理
大文件（>200MB）还用 ioutil.ReadFile + strings.Split？赶紧停手
这招在配置文件里图省事可以，但面对日志、导出数据等真实大文件，等于主动申请 OOM —— 整个文件进内存，再为每行生成字符串头和 slice 头，内存占用轻松翻 2–3 倍。
立即学习“go语言免费学习笔记（深入）”；
-
ioutil.ReadFile已被弃用，应改用os.ReadFile，但本质问题没变 - 即使加
runtime.GC()也救不回峰值内存，GC 压力反而更大 - 真要随机访问所有行？考虑
mmap（用golang.org/x/exp/mmap）或分块预加载，而不是全量加载 - 流式处理才是正路：
Scanner或Reader配合结构化解析（如encoding/csv），边读边处理，内存恒定
最常被跳过的细节是：对 ReadLine() 返回的 isPrefix == true 不做循环拼接，或把 scanner.Bytes() 结果直接塞进 map —— 这些都不是边界情况，是日常踩坑高频点。处理前多看一眼文档里那句 “the returned slice points to data that will be overwritten by the next call” 就能避开一大半问题。
