直接go processfile(path)易拖垮服务，因goroutine无节制启动导致栈内存暴涨、gc频繁、调度积压及i/o阻塞引发句柄/连接耗尽；应改用channel+固定worker池，以sync.waitgroup管控生命周期、chan作任务队列、for-select实现带取消的限流处理。
为什么直接 go processFile(path) 会出问题
任务量一过几百，go processFile(path) 就容易把服务拖垮。不是因为 Go 协程重，而是调度器和内存扛不住：每个 goroutine 初始栈占 2KB，1000 个就是 2MB；上万时 GC 开始频繁扫描、runtime 调度队列积压、runtime: out of memory 报错概率陡增。更隐蔽的问题是——文件处理常含 I/O 阻塞（如读大文件、调外部 API），协程卡住不退，新协程又不断起，最终耗尽文件句柄或数据库连接。
用 channel + 固定 worker 数实现最小可用池
不用第三方库也能稳住，核心就三样：sync.WaitGroup 管生命周期、chan string 当任务队列、固定数量的 for-select 循环当 worker。关键不是“池有多智能”，而是“有没有硬限流”。
- 任务 channel 建议用无缓冲或小缓冲（如
make(chan string, 16)），避免积压掩盖瓶颈 - worker 启动前必须
wg.Add(1)，退出前必须wg.Done()，否则wg.Wait()永远不返回 - worker 的循环不能只写
for path := range ch，得加select支持取消：for { select { case path, ok :=
filepath.Walk 和 worker 池怎么安全衔接
filepath.Walk 是同步遍历，适合做“生产者”；但别在回调里直接发任务到 channel——如果 channel 满了且没缓冲，会阻塞整个 Walk，导致目录遍历卡死。正确做法是先收全路径，再批量塞入 channel，或用带缓冲 channel + 非阻塞发送。
- 推荐方式：用
sync.WaitGroup控制 Walk 完成后再 close channel，避免 worker 读到 closed channel 还没处理完最后一个任务 - 错误示范：
for _, path := range paths { ch —— 若 <code>ch是无缓冲，且所有 worker 全在忙，这一行就卡住 - 稳妥写法：用
select+default做非阻塞发送，失败时 log 或丢弃（视业务容忍度）：select { case ch
大文件或高延迟操作下，worker 池容易漏掉 panic 或超时
文件处理函数里一个未 recover 的 panic，会让整个 worker 退出，后续任务没人消费；长时间阻塞（比如某个文件读取卡死）也会让该 worker “消失”，并发数悄悄下降。这不是池设计缺陷，而是没补全防护。
- 每个 worker 必须包一层
defer func() { recover() }()，否则一次 panic 就少一个 worker - 对单文件处理加 context 超时控制，例如
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)，并在processSingleFile内部检查ctx.Done() - 别依赖
close(ch)当“所有任务已发完”的信号——要等wg.Wait()才算真正结束；close(ch)只是告诉 worker “不再来新任务了”
真正难的不是写出让程序跑起来的协程池，而是想清楚：哪些错误该吞、哪些该透出、哪个环节必须有超时、哪次 panic 会导致 worker 永久性减少。这些细节不补全，池子建得再漂亮，上线后照样掉链子。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
