bufio.Scanner 默认不适合读超大日志文件，因单行超64KB会静默失败；应调大Buffer与MaxScanTokenSize、用Bytes()避免拷贝，或改用bufio.Reader手动控制。
bufio.Scanner 默认不适合读超大日志文件——它会在单行超 64KB 时直接失败，且小字符串高频分配拖垮 GC；真要稳定处理，得换思路：按需调大缓冲、用 scanner.Bytes() 避免拷贝，或干脆切到 bufio.Reader 手动控制。
为什么 scanner.Scan() 突然返回 false 且不报错？
这不是 bug，是设计行为：bufio.Scanner 在某行长度超过 MaxScanTokenSize（默认 64KB）时，scanner.Scan() 返回 false，同时 scanner.Err() 返回 bufio.Scanner: token too long。它不会跳过这行，也不会继续读，整个扫描就此终止。
- 常见现象：日志含超长堆栈、Base64 编码块、嵌套 JSON，一碰到就卡死
- 必须显式检查
scanner.Err()，否则错误被静默吞掉 - 仅靠
scanner.Buffer()增大底层数组没用——第二个参数（最大 token 长度）也得同步设大，否则照样失败
如何安全设置 scanner.Buffer()？
缓冲区不是越大越好，关键要匹配你日志的实际行长分布。盲目设成 1MB 对 10MB 单行依然无效，还浪费内存。
- 先粗估最长行：
head -n 10000 huge.log | awk '{print length}' | sort -n | tail -1，再加 20% 余量 - 必须在
scanner.Scan()调用前设置，否则无效 - 代码写法：
scanner.Buffer(make([]byte, 1024*1024), 1024*1024)—— 第一个参数是底层数组容量，第二个是允许的最大 token 长度 - 若只需读取不修改，优先用
scanner.Bytes()替代scanner.Text()，省一次内存拷贝；但注意返回的[]byte是缓冲区引用，循环中必须append([]byte{}, line...)复制后使用
什么时候该放弃 Scanner 改用 bufio.Reader？
当你无法预估日志单行上限，或频繁出现不可控长行（如二进制 dump 混入文本），Scanner 就退化为负担。此时 bufio.Reader 提供更底层、更可控的读取能力。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
reader.ReadString('\n')或reader.ReadBytes('\n')可捕获每行并自行判断长度，超长时可截断、告警或跳过 - 能可靠处理末尾无换行符的最后一行：
if err == io.EOF && len(line) > 0 - 没有隐式 token 限制，错误可细粒度处理，比如对
io.ErrUnexpectedEOF做降级逻辑 - 代价是代码略冗长，但换来的是健壮性——尤其在线上日志解析这种不能丢数据的场景
并发读多个大日志文件时最易踩的坑
并发本身不难，难点在于资源隔离和状态共享。多个 goroutine 共用同一个 bufio.Scanner 实例会直接 panic，而未约束 channel 缓冲大小则可能吃光内存。
- 每个文件必须配独立的
*os.File和bufio.Scanner（或bufio.Reader），绝不能复用 - 输出 channel 缓冲区建议设小（如
chan string, 10），避免内存堆积；100000 的缓冲在 400 万行文件下可能多占几百 MB - 写入协程数别贪多，磁盘 I/O 是瓶颈，4–10 个通常足够；更多反而因调度开销拖慢整体速度
- 所有
scanner.Err()必须检查，权限问题或文件损坏不该导致静默失败
真正麻烦的从来不是“怎么读”，而是“读错了怎么办”——超长行要不要截断？损坏行要不要跳过？最后一行没换行符算不算完整？这些边界逻辑，比选哪个 API 更消耗心力。
