使用 `sync.waitgroup` 配合带缓冲的通道和结构化结果类型，是 go 中处理未知深度递归爬虫并安全关闭通道的惯用方案。
在 Go 的并发编程中，递归启动 Goroutine（如网页爬虫）时，常面临一个经典难题：如何在所有子 Goroutine 完成后，优雅地停止从结果通道读取，避免死锁或资源泄漏？ 由于递归分支数量动态不可知，无法预先关闭通道；而若在主 Goroutine 中直接 close() 通道，又可能因竞态导致 panic 或漏读数据。
标准、符合 Go 惯用法（idiomatic Go）的解法是 “WaitGroup + 结构化结果通道 + 单独消费协程” 模式：
- sync.WaitGroup 跟踪活跃 Goroutine：每启动一个新 Goroutine 前调用 wg.Add(1)，函数退出前 defer wg.Done()，确保计数精确；
- 结果与错误统一建模：定义 Results 结构体，内含带缓冲的 Data chan [2]string 和 Error chan error（缓冲大小为 1 可避免 Goroutine 因发送阻塞而卡死）；
- 独立消费协程负责读取：启动一个 go results.Read() 协程，在 for-select 循环中持续读取，直到通道被显式关闭；
- 主流程控制生命周期：main 中调用 wg.Wait() 等待全部爬取完成，再调用 results.Close() 关闭两个通道——此时 Read() 中的 select 将自然退出循环（因已关闭的通道可立即读出零值，但更稳妥的做法是配合 ok 判断；本例通过 defer results.Close() + for {} + 通道关闭语义实现简洁终止）；
- 线程安全缓存防重复：用 sync.Mutex 包裹 map[string]struct{} 实现原子性 AtomicSet()，避免 if !exists { set } 引发的竞态。
以下是关键逻辑精简示例（省略 fakeFetcher 等辅助代码）：
func Crawl(wg *sync.WaitGroup, url string, depth int, fetcher Fetcher, cache *UrlCache, results *Results) {
defer wg.Done()
if depth <= 0 || !cache.AtomicSet(url) {
return
}
body, urls, err := fetcher.Fetch(url)
if err != nil {
results.Error <- err // 缓冲通道，不会阻塞
return
}
results.Data <- [2]string{url, body}
for _, u := range urls {
wg.Add(1)
go Crawl(wg, u, depth-1, fetcher, cache, results)
}
}
func main() {
var wg sync.WaitGroup
cache := NewUrlCache()
results := NewResults()
defer results.Close() // 确保退出前关闭通道
wg.Add(1)
go Crawl(&wg, "http://golang.org/", 4, fetcher, cache, results)
go results.Read() // 启动非阻塞消费者
wg.Wait() // 等待所有爬取完成
}⚠️ 注意事项：
- 切勿在 Crawl 中关闭 results.Data/Error：多个 Goroutine 并发写入，关闭操作只能由单一协程执行；
- Results.Read() 使用无限 for + select 是安全的，因为 close() 后
- UrlCache.AtomicSet() 必须将检查与插入合并为原子操作，否则仍存在竞态风险；
- 若需更高性能，可考虑 sync.Map（适用于读多写少）或第三方并发安全 map，但对本练习而言，Mutex + map 更清晰、更符合教学目的。
这正是 Tour of Go 第 73 节所期望的思维范式：用组合代替继承，用明确的同步原语（WaitGroup）替代隐式控制流，用结构化通道通信替代共享内存——简洁、健壮、且一眼可知其并发契约。
