使用 `sync.waitgroup` 配合带缓冲的通道和结构化结果类型，是 go 中处理未知深度递归爬虫并安全关闭通道的惯用方案。

在 Go 的并发编程中，递归启动 Goroutine（如网页爬虫）时，常面临一个经典难题：如何在所有子 Goroutine 完成后，优雅地停止从结果通道读取，避免死锁或资源泄漏？ 由于递归分支数量动态不可知，无法预先关闭通道；而若在主 Goroutine 中直接 close() 通道，又可能因竞态导致 panic 或漏读数据。

标准、符合 Go 惯用法（idiomatic Go）的解法是 “WaitGroup + 结构化结果通道 + 单独消费协程” 模式：

1. sync.WaitGroup 跟踪活跃 Goroutine：每启动一个新 Goroutine 前调用 wg.Add(1)，函数退出前 defer wg.Done()，确保计数精确；
2. 结果与错误统一建模：定义 Results 结构体，内含带缓冲的 Data chan [2]string 和 Error chan error（缓冲大小为 1 可避免 Goroutine 因发送阻塞而卡死）；
3. 独立消费协程负责读取：启动一个 go results.Read() 协程，在 for-select 循环中持续读取，直到通道被显式关闭；
4. 主流程控制生命周期：main 中调用 wg.Wait() 等待全部爬取完成，再调用 results.Close() 关闭两个通道——此时 Read() 中的 select 将自然退出循环（因已关闭的通道可立即读出零值，但更稳妥的做法是配合 ok 判断；本例通过 defer results.Close() + for {} + 通道关闭语义实现简洁终止）；
5. 线程安全缓存防重复：用 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）替代隐式控制流，用结构化通道通信替代共享内存——简洁、健壮、且一眼可知其并发契约。