应使用 sync.waitgroup 同步 goroutine：启动前 wg.add(1)，函数末尾 wg.done()，主 goroutine 调用 wg.wait()；并发控制用带缓冲 channel 作信号量，如 sem := make(chan struct{}, 10)。
goroutine 启动后文件扫描不等待就退出？
Go 程序启动 go scanFile(filepath) 后主 goroutine 立即返回或退出，导致子 goroutine 被强制终止。根本原因是缺少同步机制——Go 不会自动等待未完成的 goroutine。
正确做法是用 sync.WaitGroup 显式跟踪任务数量：
- 在启动每个
go scanFile()前调用wg.Add(1) - 在
scanFile函数末尾（无论成功失败）调用wg.Done() - 主 goroutine 在所有
go启动后，调用wg.Wait()阻塞等待
别用 time.Sleep 模拟等待——它不可靠，且掩盖了同步缺失的本质问题。
如何限制并发数避免 open too many files 错误？
直接对每个文件起一个 goroutine，遇到几千个文件时极易触发系统级错误：too many open files。这不是 Go 问题，而是操作系统对进程打开文件描述符数量的硬限制（通常 1024）。
必须引入并发控制，推荐用带缓冲的 channel 作为计数信号量：
sem := make(chan struct{}, 10) // 最多同时处理 10 个文件
for _, path := range files {
sem <p>注意：必须用 <code>func(p string)</code> 显式传参，否则闭包捕获循环变量 <code>path</code> 会导致所有 goroutine 扫描最后一个路径。</p><h3>scanFile 中读取文件内容时 panic: invalid memory address？</h3><p>常见于用 <code>ioutil.ReadFile</code>（Go 1.16+ 已弃用）或 <code>os.ReadFile</code> 后直接操作返回的字节切片，但未检查错误。一旦文件不存在、权限不足或被删除，<code>err != nil</code>，而 <code>data</code> 是 <code>nil</code>，后续 <code>strings.Contains(data, "keyword")</code> 就 panic。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0"><img
src="https://img.php.cn/upload/manual/001/589/237/6a6adeed24a4a355.png" alt="Go语言（Golang）1.26.0" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0" class="overflowclass">Go语言（Golang）1.26.0</a>
<p class="overflowclass">Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><p>必须始终先判错：</p><pre class="brush:php;toolbar:false;">data, err := os.ReadFile(path)
if err != nil {
log.Printf("skip %s: %v", path, err)
return
}
// 此时 data 才可安全使用另外，大文件（如 >100MB）不宜全量读入内存，应改用 bufio.Scanner 流式处理，否则可能触发 OOM。
为什么 filepath.WalkDir 比 filepath.Walk 更适合并发扫描？
filepath.Walk 是同步阻塞调用，内部递归遍历目录树，无法在遍历中途插入 goroutine；而 filepath.WalkDir（Go 1.16+）支持在回调中返回 filepath.SkipDir 或直接并发启动扫描，更灵活。
典型模式是：用 WalkDir 收集文件路径到切片，再分发给 worker goroutine；或更进一步，在回调里直接做轻量判断（如扩展名过滤），符合条件才发给扫描池：
filepath.WalkDir(root, func(path string, d fs.DirEntry, err error) error {
if err != nil {
return nil // 忽略权限错误等
}
if !d.IsDir() && strings.HasSuffix(d.Name(), ".log") {
sem <p>注意 <code>WalkDir</code> 的回调函数本身运行在主线程，不能在其中做耗时操作（如实际读文件），否则会拖慢整个遍历过程。</p><p>并发文件扫描真正的难点不在启动 goroutine，而在错误传播、资源回收和边界控制——比如某个文件卡死读取，是否要加超时？日志输出是否需要加锁？扫描结果如何安全聚合？这些细节不处理，程序在真实环境大概率静默失败。</p>golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
