本文讲解如何使用 `sync.waitgroup` 替代手动管理 channel 关闭时机，解决并发爬虫中“何时确认无新任务、何时终止等待”的核心问题，避免死锁与过早关闭。
在 Go 的并发爬虫实现中（如 Go Tour 并发练习：Web Crawler），一个常见误区是试图通过监听 channel 长度（如 len(stor.Queue) == 0）或在 goroutine 中随意关闭 channel 来判断“所有任务已完成”。这不仅逻辑错误（channel 长度为 0 不代表后续无写入），更会导致 panic（向已关闭 channel 发送数据）或死锁（主 goroutine 永远阻塞在 range 上）。
正确的做法是：不依赖 channel 关闭来驱动流程控制，而用 sync.WaitGroup 显式跟踪活跃的 goroutine 数量。WaitGroup 提供了三个核心方法：
- Add(n)：增加待等待的 goroutine 计数；
- Done()：当前 goroutine 完成，计数减一；
- Wait()：阻塞直到计数归零。
以下是关键改造要点：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
✅ 移除共享 channel 驱动的循环模型
原代码中 for res := range stor.Queue { go Crawl(...) } 本质是串行消费 + 并发派生，但因 stor.Queue 永不关闭，range 永不退出，造成死锁。应彻底弃用该模式。
✅ 将任务分发内聚到 Crawl 函数内部
每个 Crawl 实例在获取子 URL 后，立即为每个新 URL 启动新的 goroutine，并同步调用 wg.Add(1)。这样任务树的拓扑结构与 WaitGroup 计数严格对应。
✅ 统一使用全局（或传入）WaitGroup，避免状态分散
本例中 visited 和 wg 均声明为包级变量，确保所有 goroutine 可见且操作原子。若需更高封装性，可将 *sync.WaitGroup 作为参数传入 Crawl，但需注意避免拷贝（必须传指针）。
✅ 主流程：启动根任务 → 等待全部完成
func main() {
wg.Add(1) // 根任务计入
go Crawl(Result{"http://golang.org/", 4}, fetcher)
wg.Wait() // 阻塞直至所有 goroutine 调用 Done()
}⚠️ 注意事项：
- wg.Add(1) 必须在 go 启动前调用，否则存在竞态（Done() 可能在 Add() 前执行）；
- defer wg.Done() 应置于函数起始处，确保任何路径（包括 panic）都能释放计数；
- visited 映射需配合互斥锁（如 sync.Mutex）用于真实场景——本例因 fakeFetcher 数据固定且无并发写冲突，可省略，但生产环境必须加锁；
- 若需结果收集（如汇总抓取页数），建议额外使用带缓冲的 channel（如 results := make(chan string, 100)）配合 close(results) + for r := range results 安全消费。
综上，sync.WaitGroup 是 Go 中协调“动态数量 goroutine 生命周期”的标准、可靠且轻量的方案。它将“是否还有任务”这一逻辑问题，转化为清晰的计数问题，彻底规避了 channel 关闭时机难以判定的陷阱。
