Go 1.16+ 推荐用 filepath.WalkDir 替代 Walk，因其按需读取、内存可控、可规避 symlink 循环 panic，并支持错误处理与 SkipDir；匹配文件名宜用 filepath.Base + strings.Contains，避免正则滥用与路径误匹配。
用 filepath.WalkDir 遍历目录比 filepath.Walk 更安全
Go 1.16+ 推荐优先用 filepath.WalkDir，它按需读取目录项、不缓存全部文件名，内存更可控，且能避免某些符号链接循环导致的 panic。旧版 filepath.Walk 在遇到权限不足或损坏的 symlink 时容易直接崩溃，而 WalkDir 允许你在回调中返回 filepath.SkipDir 或忽略错误继续遍历。
实操建议：
- 始终传入一个非 nil 的
fs.DirEntry参数，在回调里用entry.Name()和entry.IsDir()判断，别再依赖os.Stat多查一次 - 如果要跳过
.git或node_modules，在回调开头加判断：if entry.Name() == ".git" && entry.IsDir() { return filepath.SkipDir } - 注意：
WalkDir不保证路径顺序，如需排序，先收集路径再sort.Strings
匹配文件名用 filepath.Base + strings.Contains 就够了
多数搜索场景只需模糊匹配文件名（比如搜 "config" 找 config.yaml、my_config.go），不需要正则。用 filepath.Base(path) 提取文件名后直接 strings.Contains，简单、快、无编译开销。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 误用
strings.Contains(path, keyword)—— 会把完整路径当字符串匹配，搜"log"可能命中/var/log/app.log里的/log/目录名，结果错乱 - 过度使用
regexp.MustCompile—— 每次匹配都编译正则，性能差，且用户输错语法直接 panic - 忽略大小写需求 —— 可改用
strings.Contains(strings.ToLower(filepath.Base(path)), strings.ToLower(keyword))
支持通配符（*）得自己解析，别依赖 filepath.Match
filepath.Match("*.go", "main.go") 看似方便，但它只支持简单模式（*、?、[...]），且不处理路径层级 —— 比如 "**/*.go" 会失败。真实搜索工具需要递归通配，得手动拆解模式。
实操建议：
- 把用户输入如
"src/**/test_*.go"拆成两部分："src"是起始路径，"**/test_*.go"是相对匹配模式 - 对每个遍历到的
entry，用strings.TrimPrefix(fullPath, root)得到相对路径，再用path.Match(pattern, relPath)判断 - 注意：
path.Match中的**并不被支持，需自行展开为多层filepath.WalkDir或改用第三方库如gobwas/glob
并发搜索多个目录时小心 os.File 资源耗尽
启动 10 个 goroutine 同时 WalkDir 十几个大目录，很容易触发 “too many open files” 错误 —— 每个 WalkDir 在深层目录中会打开大量 os.File（尤其是 readdir 系统调用）。这不是 Go bug，是 OS 文件描述符限制。
解决方法很实在：
- 用
semaphore控制并发数，例如golang.org/x/sync/semaphore，每启动一个 goroutine 前acquire，结束后release - 设上限为
runtime.NumCPU() * 2或硬编码为 4～8，别盲目用runtime.NumCPU() - Linux 下临时调高 ulimit：
ulimit -n 4096，但生产环境必须靠限流，不能靠调系统参数
真正难处理的是用户一边输入模糊关键字、一边实时刷新结果 —— 这时候得加 context 取消和结果 channel 缓冲，否则旧搜索没结束新搜索又来，goroutine 泄漏风险很高。
