filepath.walkdir比filepath.walk快2～3倍，因其一次性读取目录项且不自动stat；但若在回调中无条件调用os.stat，会抵消全部性能优势，正确做法是仅对目标文件调entry.info()、用entry.isdir()和entry.name()轻量判断、提前return filepath.skipdir过滤子目录。
直接用 filepath.WalkDir 就能跑得比老式 filepath.Walk 快 2～3 倍，但多数人一写就掉进性能陷阱——不是 Go 不够快，是默认用法在反复触发系统调用。
为什么 filepath.WalkDir 回调里调 os.Stat 就废了
filepath.WalkDir 的优势在于一次性读目录项、不自动 stat；一旦你在回调里对每个 entry 调 os.Stat(path)，等于把省下的系统调用又全还回去。
- 只判断是否为目录：用
entry.IsDir()，它不触发 syscall - 只取文件名匹配：用
entry.Name()，别拼完整路径再path.Ext() - 真需要大小或时间戳：缓存调用，且只对命中目标的路径调一次
entry.Info()（内部已缓存首次结果） - 别在循环里写
if _, err := os.Stat(p); err == nil { ... }—— 这是典型退化写法
提前过滤比遍历完再筛快一个数量级
海量小文件场景下，90% 的 I/O 开销花在打开/关闭不需要的路径上。过滤必须发生在进入子目录前，而不是等 entry 拿到手再判断。
- 维护一个忽略列表：如
[]string{"node_modules", ".git", "vendor"}，用map[string]struct{}查 O(1) - 跳过子目录：在回调中检查
path（不是entry.Name()），若匹配忽略规则，直接 returnfilepath.SkipDir - 文件名后缀匹配：用
strings.HasSuffix(entry.Name(), ".log")，别用path.Ext(path) == ".log"（会多一次路径解析） - 大小范围筛选：仅对
entry.IsDir() == false的项调entry.Info().Size()，避免对目录做无谓 stat
并发不是万能解药，反而容易拖垮磁盘
盲目给每个子目录起 goroutine，会导致 fd 耗尽、内核调度抖动、随机 IO 雪崩。真正有效的并发粒度是「每个 worker 处理一个子树根目录」，而非单个文件。
- 用带缓冲 channel 控制活跃 worker 数：如
sem := make(chan struct{}, 4)，每启动前sem ，结束时 <code> - 每个 goroutine 接收一个目录路径，内部用同步
filepath.WalkDir完成整棵子树扫描 - 别用
runtime.GOMAXPROCS硬拉高数值——磁盘是阻塞型瓶颈，CPU 核心数无关紧要 - 如果目标是找第一个匹配项，用自定义 error（如
errFound）提前中断，外层用errors.Is(err, errFound)捕获，别靠 channel 发送信号
大文件内容搜索别加载全量，要跳转读取
对 >1MB 的文件做关键词搜索，os.ReadFile 或 bufio.Scanner 全量读取既慢又吃内存。关键不是“怎么读快”，而是“怎么读得少”。
- 顺序扫描：用
os.Open+bufio.NewReaderSize(f, 64*1024)，缓冲设 64KB 减少 syscall 次数 - 只查文件头（如 magic bytes）：用
file.ReadAt(buf[:8], 0)，零 seek 开销 - 已知偏移定位：用
file.Seek(offset, io.SeekStart)+io.ReadFull(file, buf)精确读，不依赖 scanner 临时切片 - 高频关键词查同一大文件：预建
*suffixarray.Index，但仅限启动时构建一次，别每次 new
最容易被忽略的是：filepath.WalkDir 不保证遍历顺序，也不处理软链接环路——你得自己加递归深度计数器和已访问路径哈希表，否则在 /proc/self/fd 这类路径下会卡死或栈溢出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
