goroutine 启动后立即阻塞导致目录遍历无结果，主goroutine提前退出；应封装遍历函数并配合sync.WaitGroup或channel同步，避免共享filepath.WalkDir实例，按一级子目录分发任务，并正确管理channel关闭与缓冲。
goroutine 启动后立即阻塞，目录遍历没结果？
常见原因是用 range filepath.WalkDir 或 filepath.Walk 时没配合 sync.WaitGroup 或通道同步，goroutine 启动就返回，主 goroutine 退出，整个程序结束。遍历逻辑哪怕写了，也根本没机会执行。
正确做法是：把遍历封装成函数，用 go 启动，同时用 sync.WaitGroup 记录任务数，或通过 chan 收集结果并等待关闭。
- 别在 goroutine 里直接调用
log.Fatal或os.Exit，会杀掉整个进程 - 每个 goroutine 应该只负责一个子目录（比如按路径前缀拆分），避免多个 goroutine 竞争同一
filepath.WalkDir实例 - 如果用
filepath.WalkDir，注意它本身不是并发安全的，不能被多个 goroutine 共享调用
如何安全地把目录树拆给多个 goroutine 处理？
不能靠“平均分目录数量”，因为子目录深度和文件量差异极大。更稳妥的方式是：主 goroutine 先做一层浅层扫描（只到第一级子目录），然后为每个子目录启一个 goroutine 单独遍历。
例如：/data 下有 /data/a、/data/b、/data/c，就启动三个 goroutine，分别调用 filepath.WalkDir("/data/a", ...)、filepath.WalkDir("/data/b", ...) 等。
立即学习“go语言免费学习笔记（深入）”；
- 用
os.ReadDir获取一级子项，过滤出IsDir()为true的条目 - 每个子目录路径传入独立的 goroutine，避免共享状态
- 若某子目录为空或权限不足，对应 goroutine 内部处理错误，不要 panic 或传播到主流程
用 channel 收集结果时为什么总是死锁或漏数据？
典型错误是：channel 未设缓冲且发送端未关闭，接收端用 for range ch 一直等；或者多个 goroutine 往同一个无缓冲 channel 发送，但没控制并发数，导致某个 goroutine 永远卡在 ch 。
建议方案：使用带缓冲的 channel（如 make(chan string, 1000)），并在每个 goroutine 结束前关闭自己的私有 channel（不推荐）；更推荐主 goroutine 管理一个统一 channel，配合 sync.WaitGroup + close() 控制关闭时机。
- 启动所有 goroutine 后，另起一个 goroutine 调用
defer close(ch)并等待wg.Wait() - 接收方用
for path := range ch安全消费，不会死锁 - 避免对同一 channel 大量高频写入（如每文件都发一次），可考虑批量聚合后发送，减少调度开销
filepath.WalkDir 和 filepath.Walk 在并发场景下有什么关键区别？
filepath.WalkDir 是 Go 1.16+ 引入的替代方案，它用 fs.DirEntry 避免了多次 stat 系统调用，在性能和资源占用上明显优于 filepath.Walk。并发中尤其重要——每个 goroutine 独立调用 WalkDir，不会因重复 stat 拖慢整体速度。
-
WalkDir的回调函数签名为func(path string, d fs.DirEntry, err error) error，d已含类型和基本信息，无需再os.Stat -
Walk的回调是func(path string, info os.FileInfo, err error) error，每次都会触发一次stat，并发时 I/O 放大效应明显 - 若需兼容旧版本 Go，必须降级用
Walk，但应加缓存（如map[string]os.FileInfo）避免重复 stat，不过这又引入 map 并发写风险
实际项目里，只要 Go ≥ 1.16，无条件选 filepath.WalkDir。真正容易被忽略的是：即使用了它，如果在回调里又调用了 os.Stat 或 os.ReadDir，照样会退化成多趟系统调用——得养成看 d.Type() 和 d.Info() 是否已满足需求的习惯。
