协程池无法解决文件描述符耗尽问题，核心在于需限制同时打开的文件数而非goroutine数；应使用带缓冲channel（如sem := make(chan struct{}, 32)）实现fd限流，确保任意时刻最多N个文件被打开。
协程池不是万能加速器，对超大字符串文件做并发匹配，核心矛盾从来不是“CPU 不够用”，而是“文件描述符耗尽”和“内存失控”。盲目起 100 个 goroutine 去 os.Open 100 个文件，open: too many open files 会在 3 秒内报给你看。
为什么不能直接用 goroutine 池暴力扫所有文件
每个 os.Open 占一个文件描述符（fd），Linux 默认单进程上限是 1024。目录里若有 500 个日志文件，开 500 个 goroutine 就等于申请 500 个 fd —— 还没开始匹配，系统就拒绝再打开新文件。更糟的是：defer f.Close() 放在 goroutine 里不等于“立刻关”，fd 会堆积到池满才释放，根本起不到限流作用。
- runtime.NumCPU() 控制 goroutine 数量毫无意义：它管调度，不管 fd
- 用
sync.WaitGroup等待所有 goroutine 结束，也救不了 fd 泄漏 - 真正要锁住的，是“同时打开的文件数”，不是“同时运行的 goroutine 数”
用带缓冲 channel 实现安全的 fd 限流
本质是建一个“许可证池”：容量为 N 的 chan struct{}，每次打开前先取一个 token，处理完再归还。这样就能硬性保证任意时刻最多 N 个文件被打开。
sem := make(chan struct{}, 32) // 同时最多打开 32 个文件
for _, path := range files {
sem <- struct{}{} // 拿许可证
go func(p string) {
defer func() { <-sem }() // 还许可证，必须放 defer 里
<pre class="brush:php;toolbar:false;"> f, err := os.Open(p)
if err != nil {
log.Printf("skip %s: %v", p, err)
return
}
defer f.Close() // 此处 Close 才真释放 fd
scanner := bufio.NewScanner(f)
scanner.Buffer(make([]byte, 64*1024), 1<<20) // 防超长行截断
for scanner.Scan() {
line := scanner.Bytes() // 用 []byte 避免 string 分配
if bytes.Contains(line, []byte("ERROR")) {
fmt.Printf("%s: %s\n", p, line)
}
}
}(path)}
立即学习“go语言免费学习笔记（深入）”；
逐行匹配时别碰 strings.Index 和正则黑洞
对 ASCII 关键词（如 "ERROR"、"404"）做高频匹配，strings.Index 是最慢选择——它强制把 []byte 转成 string，触发堆分配；而 bytes.Contains 零分配、直接操作字节切片，快 2–3 倍。
- 忽略大小写搜索？别写
strings.Contains(strings.ToLower(line), "error")，改用strings.EqualFold，不分配且语义正确 - 要同时查多个关键词（如
"GET|POST|PUT"）？循环调bytes.Contains是最差方案；用regexp.MustCompile，Go 的regexp包对简单模式会自动编译为 Aho-Corasick 类状态机 - pattern 长度 > 64 字节？预编译
regexp仍比手写 KMP 快，因标准库做了 UTF-8 边界优化，你手写的容易 panic 或错位
超大单文件内部并发扫描反而有害
一个 8GB 的日志文件，不要试图用 16 个 goroutine 分块读——bufio.Scanner 不支持随机偏移，强行切块得自己 io.ReadAt + bytes.Split 做行边界对齐，极易丢行或错乱。真实场景中，单文件流式扫描已足够快，瓶颈在磁盘 I/O，不在 CPU。
- 用
os.Open+bufio.Scanner即可，别碰ioutil.ReadFile（已弃用）或os.ReadFile（OOM 风险高） - 超长行（如 minified JSON）会触发
scanner: token too long，必须显式调scanner.Buffer - GBK/GB2312 编码？
bufio.Scanner会乱码，得先用golang.org/x/text/encoding转 UTF-8 再扫 - 如果真要分块读单大文件，请用
io.ReadAt+sync.Pool复用缓冲区，但这是另一套工程方案，和“多文件匹配”无关
最容易被忽略的点：匹配结果本身不占多少内存，但把每行 scanner.Text() 存进 slice、或者用 fmt.Sprintf 拼接日志，会瞬间让 GC 崩溃。输出环节必须节制——要么直接 fmt.Printf，要么用 bufio.Writer 批量刷盘，别攒着。
