直接go parseline(line)会拖垮服务，因10万行启动10万个goroutine，初始栈耗200mb内存，gc压力剧增并易触发oom；若含阻塞调用则goroutine堆积，迅速耗尽文件句柄或连接池。
为什么直接 go parseLine(line) 会把解析服务拖垮
不是协程太重，是失控的并发把内存和调度器压垮了。每个 go parseLine(line) 启一个 goroutine，10 万行就是 10 万个初始栈（2KB × 10w ≈ 200MB），GC 开始频繁扫描堆，runtime: out of memory 报错概率陡增。更隐蔽的是：若某行含 os.Open 或网络调用，卡住的 goroutine 不退，新 goroutine 又不停起，最终耗尽文件句柄或连接池。
协程池只该用于“高成本处理”，别用它遍历目录
很多人误把 filepath.WalkDir 和协程池混在一起——这是典型用力过猛。磁盘 I/O 是瓶颈，不是 CPU；并发读目录反而破坏顺序读、增加锁竞争。实测 50 万小文件，filepath.WalkDir 耗时 1.2s，而为每个子目录启 goroutine + os.ReadDir 升至 3.7s。
- 正确分工：
filepath.WalkDir单协程收全路径（快且安全），再把路径列表交给协程池做后续处理 - 若处理逻辑含
os.Open或计算 SHA256，池大小建议设为 4–8；SSD 上别超 16，机械盘 ≤4 - 跳过
.git必须用strings.EqualFold(d.Name(), ".git")，Windows 大小写不敏感，== ".git"会漏
任务 channel 缓冲区大小怎么设才不踩坑
缓冲区不是越大越好。无缓冲 channel 容易让 filepath.WalkDir 回调卡死；但缓冲太大（如 make(chan string, 10000)）会掩盖真实瓶颈，让积压任务在内存里堆积，OOM 风险翻倍。
- 推荐用小缓冲：
make(chan string, 16)或32，够撑住瞬时 burst，又不至于藏住问题 - 往 channel 发任务时，别用
ch 直接阻塞；改用 <code>select+default非阻塞发送，失败时可丢弃或打日志 - 关闭 channel 前必须确保所有路径已发完，否则 worker 可能提前退出，漏掉最后一批任务
worker 内 panic 和超时怎么防住不扩散
一个未 recover 的 panic 会让整个 worker 退出，后续任务没人消费；某个大文件读取卡死，该 worker 就“消失”，并发数悄悄下降——这两类问题在线上最难排查。
- 每个 worker 循环里必须包一层
defer func() { if r := recover(); r != nil { log.Printf("panic in worker: %v", r) } }() - 对高延迟操作（如
http.Do、os.Open）加 context 超时：ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)，并传给所有下游调用 - 别在 worker 里直接用
json.Unmarshal(data, &v)，&v 会逃逸；改用预分配 struct 值传递，或用json.NewDecoder流式解码
真正难处理的不是“怎么启动 pool”，而是谁持有中间结果——一旦某个闭包意外捕获了某次解析的 []byte，它就变成长生命周期对象，既占内存又拖慢 GC 扫描。这类泄漏很难被 pprof 直接标出，得靠 go tool trace 看 goroutine 生命周期和堆分配热点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
