本文提供一个基于sync.waitgroup和channel协调的轻量级go爬虫实现，解决原代码中因goroutine未同步退出导致的死锁问题，兼顾可读性与工程健壮性。
本文提供一个基于sync.waitgroup和channel协调的轻量级go爬虫实现，解决原代码中因goroutine未同步退出导致的死锁问题，兼顾可读性与工程健壮性。
在Go Tour的Web Crawler练习中，初学者常陷入“并发即正确”的误区：盲目启动大量goroutine却忽略生命周期管理，最终触发死锁（如fatal error: all goroutines are asleep - deadlock!）。核心症结在于——没有明确的完成信号机制：主goroutine无限select等待channel数据，而子goroutine爬完后悄然退出，无人关闭channel，亦无计数器告知“工作已全部结束”。
下面是一个简洁、可运行、无死锁的重构方案，仅增加少量关键逻辑，彻底规避原问题：
✅ 正确的并发协调模型
我们采用 sync.WaitGroup + 关闭channel 的双保险策略：
-
WaitGroup跟踪所有活跃爬取goroutine数量； - 所有goroutine结束后，由main显式关闭结果通道，使
range或select能自然退出； - 避免使用未缓冲/未关闭的channel进行无限阻塞等待。
package main
import (
"fmt"
"sync"
)
type Fetcher interface {
Fetch(url string) (body string, urls []string, err error)
}
// SafeCache 使用 RWMutex 提升读多写少场景性能（推荐替代原Mutex）
type SafeCache struct {
cache map[string]bool
rwmu sync.RWMutex // 读操作无需互斥，提升并发效率
}
func (c *SafeCache) Set(url string) {
c.rwmu.Lock()
c.cache[url] = true
c.rwmu.Unlock()
}
func (c *SafeCache) Get(url string) bool {
c.rwmu.RLock()
defer c.rwmu.RUnlock()
return c.cache[url]
}
var sc = SafeCache{cache: make(map[string]bool)}
// Crawl 启动goroutine执行爬取，并通过wg通知完成
func Crawl(url string, depth int, fetcher Fetcher, wg *sync.WaitGroup, results chan<h3>? 关键改进点说明</h3>
| 原问题 | 修复方式 | 原理 |
|---|---|---|
select { case 无限等待未关闭channel |
改用 for range ch + 显式 close()
|
channel关闭后range自动退出，无死锁风险 |
wg缺失导致无法判断goroutine是否结束 |
wg.Add(1)/wg.Done()配对 + wg.Wait()阻塞主goroutine |
精确控制并发生命周期，避免过早退出或永久等待 |
SafeCache读操作加写锁，性能低 |
改用sync.RWMutex，读共享、写独占 |
符合爬虫缓存“读远多于写”的典型场景，提升吞吐 |
| channel无缓冲，易因消费者慢导致goroutine阻塞 | 设置合理缓冲（如100） | 防止生产者goroutine因channel满而挂起 |
⚠️ 注意事项
-
永远不要在未关闭的channel上
range或无限select—— 这是死锁头号原因； -
wg.Add()必须在go语句之前调用（否则存在竞态）； -
defer wg.Done()应置于函数开头，确保panic时也能释放计数； - 生产环境建议增加超时控制（如
context.WithTimeout）和重试逻辑，但本练习以清晰性为先。
该方案在保持代码简洁性的同时，严格遵循Go并发最佳实践，是理解WaitGroup与channel协作的经典范例。掌握它，你就真正迈过了Go并发编程的第一道门槛。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
