必须用带缓冲channel限流，因每个os.open占用一个文件描述符（fd），linux默认单进程上限1024，盲目并发打开数百文件会触发“too many open files”错误；defer f.close()无法解决fd堆积问题，关键在控制同时打开文件数而非goroutine数。
直接用 filepath.WalkDir + sync.WaitGroup + 限流 channel 就能跑起来，但不加并发控制会触发 too many open files 错误，这是最常踩的坑。
为什么不能直接开一堆 goroutine 读文件
每个 os.Open 都占一个文件描述符（fd），Linux 默认单进程最多 1024 个 fd。目录里几百个 .log 文件一并发打开，立刻报错：open /path/to/file: too many open files。这不是内存问题，是系统资源硬限制。
- 用
runtime.NumCPU()控制 goroutine 数量没用——它只管调度，不管 fd -
defer f.Close()放在 goroutine 里也救不了，因为关闭时机不可控，fd 会堆积 - 真正要限的是“同时打开的文件数”，不是“同时运行的 goroutine 数”
用带缓冲 channel 实现安全并发限流
核心思路：用一个容量为 N 的 channel 当“许可证池”，每次要打开文件前先从 channel 取一个 token，处理完再还回去。这样就能确保任意时刻最多 N 个文件被打开。
- 推荐初始值设为
16或32（比NumCPU()更稳妥，避免 I/O 等待拖慢整体） - channel 类型用
struct{}，零内存开销 - 不要在 defer 里放
ch ，容易因 panic 跳过；统一用 <code>defer func(){ ch
sem := make(chan struct{}, 32)
for _, path := range files {
sem <h3>逐行扫描时别用 ioutil.ReadFile</h3><p><code>ioutil.ReadFile</code> 已被弃用，且对大文件（>100MB）极易 OOM。真实日志或 dump 文件动辄 GB 级，必须流式处理。</p>
- 坚持用
os.Open+bufio.Scanner，默认每行上限 64KB，超长行会被截断——如需支持超长行，调scanner.Buffer(make([]byte, 64*1024), 1 - 如果文件是 GBK/GB2312 编码，
bufio.Scanner会乱码或报invalid UTF-8；得先用golang.org/x/text/encoding转成 UTF-8 再扫 - 忽略大小写搜索别写
strings.Contains(strings.ToLower(line), strings.ToLower(kw))——每次调都分配新字符串；改用strings.EqualFold，零分配
正则匹配必须预编译，且注意 RE2 的能力边界
Go 的 regexp 底层是 RE2，不回溯、安全但功能受限。在循环里反复 regexp.Compile 是性能黑洞，且某些语法根本无效。
- 提前编译：
r, _ := regexp.Compile(<code>^\d+\s+(ERROR|WARN))，注意 Go 字符串字面量要双反斜杠 - 不支持
(?i)内联标志？用regexp.Compile(`(?i)` + pattern)即可 - 别指望
.*?实现可靠非贪婪——RE2 对嵌套量词支持弱，复杂模式可能退化成线性扫描，响应变慢 - 想捕获分组内容，用
r.FindStringSubmatchIndex(line)拿到 byte 位置，再切片；别用FindStringSubmatch，它返回[]byte，转string又多一次拷贝
真正难的不是并发模型，而是边界：编码识别、超长行、权限拒绝、符号链接循环、空文件、scanner.Err() 类型判断（EOF 不算错）、以及如何让错误路径不阻塞整个流程——这些细节漏掉一个，工具在生产环境就卡死或静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
