bufio.Scanner 读大文件 panic 是因默认单行限64KB，遇超长行触发 makeslice 错误；解决需先确认是否真需按行读，否则改用 bufio.NewReaderSize 配合 ReadString 等流式处理方式。
bufio.Scanner 读大文件时为什么会 panic: runtime error: makeslice: len out of range
因为 bufio.Scanner 默认最大单次读取长度是 64 * 1024 字节（64KB），遇到超长行（比如日志里带超长 base64、JSON 行、无换行的二进制 dump）会直接触发该 panic。这不是 bug，而是设计上对“行”语义的保守保护。
解决方法不是盲目调大，而是先确认：你真需要按“行”读？还是只是想流式处理大文件？
- 如果文件是标准文本、每行合理（scanner.Scan() 最简洁
- 如果存在不可控长行，或根本不需要按行切分，应改用
bufio.Reader+Read()/ReadSlice('\n') - 若必须用
Scanner且确定长行安全，可调：scanner := bufio.NewScanner(file) scanner.Buffer(make([]byte, 64*1024), 16*1024*1024) // max capacity = 16MB
但注意：第二个参数不能超过math.MaxInt32，且内存占用随上限线性增长
按行读取时 Scanner 和 Reader.ReadLine() 的关键区别
bufio.Scanner 是封装层，自动跳过换行符、不返回 \n；bufio.Reader.ReadLine() 是底层接口，返回的字节切片可能包含 \r\n 或 \n，且在行过长时返回 io.ErrBufferFull 而非 panic —— 这让你能主动处理截断。
-
scanner.Text()返回string，适合后续字符串操作；reader.ReadLine()返回[]byte，零拷贝更高效，但需自己处理编码（如 UTF-8 验证） -
ReadLine()不跳过换行符，你需要手动bytes.TrimRight(line, "\r\n") - 当某行 > buffer size 时，
ReadLine()返回已读部分 +err == io.ErrBufferFull，你可以循环追加直到读完整行（或放弃）
真正高效读取 GB 级纯文本文件的推荐组合
别只盯着“一行怎么读”，先看 IO 模式：顺序扫描、随机跳转、还是正则匹配？95% 的日志分析场景，只需顺序流式处理，此时关键是减少内存分配和系统调用次数。
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Open()打开文件，避免ioutil.ReadFile()全部加载到内存 - 设置足够大的 buffer：
reader := bufio.NewReaderSize(file, 1*1024*1024) // 1MB buffer
可显著降低 syscall 次数（尤其 SSD/NVMe 下效果明显） - 用
ReadString('\n')替代Scan()可绕过 Scanner 内部状态机开销，适合简单分隔场景 - 若需解析结构化数据（如 CSV、TSV），直接上
encoding/csv并传入带大 buffer 的Reader，它内部已优化
遇到中文乱码或空行消失怎么办
Go 的 bufio 完全不处理字符编码，它只认字节。所谓“乱码”，本质是源文件用了 GBK/GB2312 而你按 UTF-8 解释；所谓“空行消失”，常因 Windows 的 \r\n 被某些处理逻辑误判为连续换行。
- 确认文件编码：用
file命令（Linux/macOS）或 VS Code 底部状态栏查看，不要靠猜测 - GBK 文件需先转 UTF-8：用
golang.org/x/text/encoding包，例如encoding/gbk.NewDecoder().Bytes(data) - 处理
\r\n时，别直接strings.Split(line, "\n")，先strings.ReplaceAll(line, "\r\n", "\n")统一换行符 - 空行判断用
strings.TrimSpace(line) == ""，而非line == ""，避免被空格、tab 干扰
实际跑起来你会发现，最影响吞吐量的往往不是 Scanner 本身，而是你每行都做 json.Unmarshal 或正则全量匹配。把解析逻辑压平、复用 sync.Pool 分配的缓冲区、关掉不必要的日志打印，比调 buffer size 更管用。
