filepath.walkdir 比 walk 快且兼容旧代码，因其使用 fs.direntry 避免重复 os.stat；bufio.scanner 需预设缓冲区防 oom 和截断，正则预编译提升匹配效率。
Go 实现文件查找器，性能瓶颈不在“找得快”，而在“别多读、别乱跳、别重复 stat”——filepath.WalkDir + bufio.Scanner + 预编译正则是当前最稳的组合，比手写递归或滥用 os.ReadDir 快 2–5 倍，内存也更可控。
为什么 filepath.WalkDir 比 Walk 快且不崩
旧代码还在用 filepath.Walk？它对每个条目都调一次 os.Stat，目录越深、文件越多，系统调用爆炸式增长。真实环境里，一个含 10 万文件的目录，Walk 可能多花 800ms 以上在重复 stat 上。
- 用
filepath.WalkDir时，回调参数是fs.DirEntry，IsDir()和Name()直接可用，无需额外 syscall - 只有真需要大小或 modtime 时，才对目标路径显式调
os.Stat（比如按 size 过滤） - 遇到权限错误（
syscall.EACCES）或软链环路，WalkDir允许你返回filepath.SkipDir或nil继续，而Walk默认 panic 或中断 - Go 1.15 及更早必须降级？那就自己缓存
os.FileInfo，别让同一路径被反复Stat
bufio.Scanner 读文件时怎么避免 OOM 和截断
日志文件动辄几百 MB，os.ReadFile 会直接申请等量内存，GC 压力陡增，甚至触发 runtime: out of memory。Scanner 是流式解法，但默认配置极易出错。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 超长行（如 minidump 或 base64 日志）会触发
scanner: token too long错误：必须提前调scanner.Buffer(make([]byte, 1（1MB 缓冲） - 匹配前别转
string：用scanner.Bytes()获取[]byte，直接喂给bytes.Contains或预编译的regexp.Regexp.Find，省掉 UTF-8 转码开销 - 记得检查
scanner.Err()：磁盘拔出、文件被删、权限突变都不会 panic，但Err()会返回非 nil，漏判就丢结果 - 逐行读不是万能：若需跨行匹配（如多行 JSON 或 stack trace），改用
bufio.NewReader+ReadBytes('\n')自控缓冲边界
正则匹配要不要预编译、怎么忽略大小写
每次回调里 regexp.Compile("(?i)error") 是典型性能雷区：编译耗时约 1.2μs，而 strings.Contains 只要 30ns——差 40 倍。但纯 Contains 又没法做单词边界或模糊匹配。
- 所有正则必须预编译为全局
*regexp.Regexp变量，比如var errRe = regexp.MustCompile(<code>(?i)\berror\b) - 忽略大小写别用
strings.ToLower(line)：它分配新字符串，且无法处理 Unicode 大小写（如土耳其语 İ），regexp.MustCompile(<code>(?i)pattern)更准更快 - 只查子串？优先用
bytes.Contains（[]byte场景）或strings.Contains（string场景），比正则快一个数量级 - 多关键词 OR 匹配？别拼
re1|re2|re3：编译慢、回溯风险高；改用多个re.Match并行判断，或构建 Aho-Corasick 有限状态机（如github.com/BobuSumisu/aho-corasick）
并发搜索时 channel 和 goroutine 怎么不翻车
加 goroutine 不等于变快。盲目开 100 个协程扫文件，反而因调度、锁竞争和 I/O 队列拥塞拖慢整体速度——尤其在机械硬盘或 NFS 上。
- 并发数别硬写 100：设为
runtime.NumCPU() * 2或更低（SSD 可稍高，HDD 建议 ≤4） - 结果 channel 别无缓冲：
ch := make(chan Result, 100)防止 sender 卡死；消费者端用for range ch，别用len(ch) == 0轮询 - 共享状态如计数器，用
sync.AtomicInt64，别用mu.Lock()+ 普通 int——后者在高并发下锁争抢严重 - 文件句柄是稀缺资源：每个 goroutine
os.Open后必须defer f.Close()，否则很快 hit ulimit -n
真正卡住性能的，从来不是算法复杂度，而是系统调用频次、内存分配节奏和错误处理盲区。比如一个没检查 scanner.Err() 的查找器，在 USB 设备意外拔出时会静默丢掉后续全部结果——这种问题压测根本暴露不了，只能靠线上日志反推。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
