bufio.Scanner不适合并发分块搜索，因其本质是流式接口，依赖内部缓冲和顺序Read，无法指定起始偏移；多goroutine共享*os.File会因Seek冲突导致漏行、重复或panic，即使单独Open也会从offset 0开始读，且自动按行切分易使块边界落在行中，造成截断与错位。
大文件并发搜索不能靠 bufio.Scanner + 多 goroutine 直接扫，那样只是并发“启动”，底层仍是串行读；真正提速必须分块随机读 + 并行处理内容。
为什么 bufio.Scanner 不适合并发分块搜索
bufio.Scanner 依赖内部缓冲和 Read 方法顺序推进，无法指定起始偏移；多个 goroutine 共享一个 *os.File 句柄调用它，会因 Seek 冲突或状态错乱导致漏行、重复或 panic。它本质是流式接口，不是随机访问工具。
- 即使每个 goroutine 单独
os.Open，Scanner仍会从 offset 0 开始读 —— 你根本控制不了起点 - 它自动按行切分，但块边界大概率落在行中间，导致某行被截断、跨块重复解析
- 内部缓冲不可控，小块读取时频繁 realloc，GC 压力明显高于手动
io.ReadAt
正确做法：用 io.ReadAt 分块 + 自定义行解析
先用 os.Stat().Size() 获取总长度，按固定块大小（如 64 * 1024）切 offset/length 区间，每个 goroutine 独立 os.Open 后调用 io.ReadAt(buf, offset) 读取原始字节，再在内存里做行边界识别（注意首尾截断行的拼接）。
- 块之间必须留 1~2 行重叠：前一块末尾的不完整行，要传给后一块开头继续补全
- 不要用
strings.Split直接切 —— 它不识别 \r\n/\n/\r 差异；推荐用bytes.IndexByte手动找换行符，更可控 - 每块结果应返回
struct{ Offset int64; Data []byte; IncompleteLine []byte }，下游负责合并与去重
并发数与缓冲区怎么设才不翻车
并发数不是看 CPU 核心数，而是看存储介质特性：SSD 可设 8–16 路，HDD 超过 4 路就开始寻道抖动，NFS/CIFS 建议 ≤2 路；缓冲区大小选 64KB 或 1MB，避开 4KB 小页频繁 syscall，也避免单次分配过大。
立即学习“go语言免费学习笔记（深入）”；
- 用
semaphore.NewWeighted(8)控制活跃 goroutine 数，比裸make(chan struct{}, N)更易扩展 - 缓冲区必须复用：
sync.Pool配New: func() interface{} { return make([]byte, 1，否则 GB 文件分千块 = 千次 malloc - 路径列表含大小差异大的文件时，先
os.Stat分组：≤10MB 的小文件走高并发（16 路），≥500MB 的大文件单独限 2 路
搜索结果合并时最容易忽略的坑
goroutine 返回顺序 ≠ offset 顺序，直接 append 到一个 slice 会错乱；更糟的是，把所有块数据 accumulate 到内存再写，等于又把整个文件 load 进来 —— 和没并发一样 OOM。
- 用
sync.Map存map[int64][]byte，key 是 offset，插入后检查是否已收齐全部块（靠总数计数器） - 拼接时按 offset 排序遍历，但不要一次性
append所有数据；边排序边写入临时文件或 channel 流式输出 - 如果最终要返回匹配行的原始行号，得在每块解析时记录“本块起始逻辑行号”，不能只靠字节偏移换算 —— 行长不均等
真正难的不是开 goroutine，而是让每一块读得准、解析得稳、拼得对、内存不爆 —— 这四点缺一不可。
