因Scanner预读缓存且无法回退，跨分片行被截断丢失；需Seek后手动找换行符对齐行首，并拼接末尾不完整行。
为什么 bufio.Scanner 直接 Scan() 会漏掉跨分片的匹配
用 os.File.Seek 把大文件粗略切成 10MB 块后，每个块单独起一个 bufio.Scanner 处理，看似并行，实则危险。因为 Scanner 内部缓冲区默认 64KB，它会预读、缓存、切分——若某行横跨第 9.9MB 到第 10.1MB，前半截在块 A 被读入缓冲但未触发 Scan()，后半截在块 B 被当新行处理，整行就断开了。更糟的是，Scanner 不提供“回退已读字节”接口，无法对齐边界。
- 不要对每个分片文件句柄单独 new Scanner
- 分片起点必须对齐到完整行首：用
file.Seek()定位后，手动io.ReadBytes('\n')向前找最近换行符，再file.Seek(1, 1)跳过它，确保下一行从头开始 - 若分片末尾不以
'\n'结尾（即最后一行没换行），需额外读取下一块开头直到遇到'\n'，拼接后处理——否则该行永远丢失
如何让 grep 式关键词搜索不卡死在超长行
日志里混着 base64 编码的二进制 blob 或超长 JSON 字段时，scanner.Text() 默认 64KB 缓冲直接 panic 报 scanner: token too long。这不是配置错，是设计使然：Scanner 为安全设了硬上限，不能靠增大缓冲区无限撑。
- 改用
bufio.NewReader(file).ReadString('\n')，自己控制每次读取长度，遇到超长行可截断或跳过 - 搜索关键词前先做长度预检：
if len(line) > 1024*1024 { continue }，避免后续strings.Contains在超大字符串上反复扫描 - 忽略大小写搜索中文/英文混合词时，别用
strings.ToLower()全量转——UTF-8 下部分字符转小写会变长，导致内存翻倍；直接用bytes.EqualFold()比较字节切片更稳
并发分片检索时 channel 数据怎么不乱
起 4 个 goroutine 分别读不同分片，结果发现所有 goroutine 返回的 []byte 内容都一样，或者某几块数据错位。根本原因是没复制缓冲区：多个 goroutine 共享同一底层数组，后一个 file.Read(buf) 覆盖前一个内容，而 channel 发送的是指针。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 发送前必须显式复制：
ch ，而不是 <code>ch - channel 缓冲区大小设为
make(chan []byte, 8)，别用无缓冲或过大值——前者阻塞读协程，后者让未消费数据堆积吃光内存 - 若处理逻辑含网络请求或 DB 写入，建议加
context.WithTimeout控制单次匹配耗时，防止某块卡住拖垮整个 pipeline
内存映射 mmap 适合分片检索吗
mmap 看起来很美：零拷贝、随机访问快。但它在分片检索场景下容易被高估。Linux 上 mmap 映射大文件没问题，但 Windows 的 golang.org/x/exp/mmap 实现不支持部分映射，且 mmap 区域一旦被 GC 回收（比如你只取某一段切片后丢弃引用），底层 page fault 可能引发不可预测延迟。
立即学习“go语言免费学习笔记（深入）”；
- 仅当你要做多次随机跳转查询（如按偏移查某行）、且文件稳定不被外部修改时，mmap 才比流式读有优势
- 分片检索本质是顺序扫描，
bufio.Reader+ 复用[]byte缓冲区（如make([]byte, 1）性能差距极小，还免去跨平台兼容性问题 - 真正要警惕的是：用 mmap 后仍调
string(buf[:n])—— 这会触发一次全量内存拷贝，反而比直接Read()更慢
分片检索最难的不是切，而是对齐和收尾。每块开头是否真为行首、末尾是否补全跨块行、channel 里传的是数据还是指针——这三个点只要错一个，结果就不可信。
