结论：用bufio.scanner分行读+手动对齐分片边界更稳；但若文件无换行，必须用io.readat或file.seek()配固定块读取。因scanner预读缓存且无法回退，跨分片行被截断丢失；需seek后手动找换行符对齐行首，并拼接末尾不完整行。
直接说结论：用 bufio.Scanner 分行读 + 手动对齐分片边界，比 mmap 或纯 file.Read() 更稳；但若文件无换行（如二进制日志、协议包），必须用 io.ReadAt 或 file.Seek() 配合固定块大小读取。
为什么 Scanner 直接分片会丢行
Scanner 内部有预读缓冲区（默认 64KB），它不保证每次 Scan() 返回的都是完整逻辑行。当一行跨两个分片（比如第 9.9MB 行末和第 10.1MB 行首），前半截被缓存在第一个 Scanner 的 buffer 里未触发 Scan，后半截在第二个 Scanner 被当作新行开头——结果整行断裂、内容错位、关键词匹配失败。
这不是 bug，是 Scanner 的设计前提：它面向“单个连续流”，不是“可切割的随机访问流”。
- 别对每个分片单独 new
bufio.Scanner，除非你手动处理边界对齐 - 分片起点必须 Seek 到行首：先
file.Seek(offset, io.SeekStart)，再用io.ReadBytes('\n')向前找上一个'\n'，然后file.Seek(1, io.SeekCurrent)跳过它 - 分片末尾若不以
'\n'结尾（即最后一行没换行符），需额外从下一分片开头读直到遇到'\n'，拼接后处理，否则该行永远丢失
超长行导致 panic 怎么办
scanner: token too long 是硬限制报错，不是配置能绕过的。Scanner 默认最大 token 是 64KB，而日志里混着 base64 blob 或嵌套 JSON 时，单行轻松破 MB 级。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 改用
bufio.NewReader(file).ReadString('\n')，自己控制每次读取行为，遇到超长行可主动截断或跳过 - 设长度阈值提前过滤：
if len(line) > 1024*1024 { continue }，避免后续strings.Contains在超大字符串上反复扫描 - 中文/英文混合关键词搜索时，别用
strings.ToLower()全量转——UTF-8 下某些字符小写形式更长，内存翻倍；用bytes.EqualFold()比较字节切片更安全
并发分片读取时数据错乱的根本原因
起多个 goroutine 各自读一个分片，结果所有输出内容一样，或某几块数据串位——这不是 channel 问题，是底层 []byte 被复用了。
- 共享同一缓冲区：多个 goroutine 调用
file.Read(buf)，后一次覆盖前一次内容，而ch 发送的是指针，channel 消费时拿到的已是脏数据 - 必须显式复制：
ch 或 <code>ch （Go 1.20+） -
ch := make(chan []byte, 8)是合理缓冲大小；无缓冲易阻塞，过大（如 1000）会让未消费数据堆积吃光内存 - 若处理含网络请求或 DB 写入，务必加
context.WithTimeout(ctx, 30*time.Second)，防止单块卡死拖垮整个 pipeline
mmap 在分片场景下为什么常被高估
mmap 看起来零拷贝、随机访问快，但它在分片检索中容易引入隐性问题：
- Linux 上没问题，Windows 下 Go 的
golang.org/x/exp/mmap不稳定，且无法精确控制页对齐后的行边界 - mmap 映射后仍需手动解析行结构，无法规避跨页行断裂问题，反而掩盖了 Scanner 的边界对齐需求
- 映射超大文件后，RSS 内存占用可能虚高（即使没访问全部区域），被系统 OOM killer 杀掉的风险上升
- 真正需要 mmap 的场景是：频繁随机跳转访问（如数据库索引）、只读且格式规整（如固定 record size 的二进制日志）；普通文本分片检索，老实用
Seek + ReadString更可控
最易被忽略的一点：分片起点对齐不是“尽量靠近”，而是“必须严格落在行首”。哪怕偏移差 1 字节，就可能让整行被切两半——而这个错误在线上环境极难复现，往往只在特定文件、特定分片大小下偶然触发。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
