Go中depth-first爬虫易卡死或饿死，因goroutine调度不可控导致深路径阻塞、其他goroutine空转；需用带深度标记的URL队列并仅从当前最大深度队列取URL，而非全局FIFO。
为什么 depth-first 在 Go 爬虫里容易卡死或饿死？
Go 的 goroutine 调度不是按调用栈深浅排队的，depth-first 依赖递归/栈式调度来“先挖到底”，但实际并发中，你发出去的几十个 http.Get 请求谁先返回、谁先解析、谁先派生子任务，完全不可控。结果就是：某条深路径卡在 DNS 超时或响应慢，其他 goroutine 却因无新 URL 可取而空转——不是 DFS，是“DFS 假象 + 随机阻塞”。
- 别用递归函数模拟 DFS；Go 里没有安全的深度递归，
stack overflow或panic: runtime: goroutine stack exceeds 1GB limit很常见 - URL 队列必须带深度标记，用
struct{ url string; depth int }而非单纯字符串，否则无法做深度截断 - 真正控制“深度优先”的关键是：每次只从**当前最大深度的待抓取队列**里取 URL，而不是全局 FIFO 或随机取
sync.Map 和 chan 哪个更适合 DFS 爬虫的 URL 去重？
sync.Map 看似省事，但 DFS 场景下它会悄悄拖慢你：每解析一个页面就要遍历所有提取的链接，挨个 LoadOrStore，而多数链接早已存在；更糟的是，sync.Map 的 range 不保证顺序，你根本没法按深度分组处理。
- 用
map[string]struct{}+sync.RWMutex更快，尤其配合预分配（比如make(map[string]struct{}, 10000)） - 去重必须在入队前做，不是出队后；否则重复 URL 会挤占 goroutine 和连接池资源
- 如果要支持重启续爬，别只靠内存 map，得把已访问 URL 写到
badger或sqlite，且索引建在url字段上
如何让 http.Client 不破坏 DFS 深度节奏？
默认 http.Client 的超时是全局的，一旦某个深层页面响应慢，整个 goroutine 就挂住，后续同深度的 URL 全被压着——这不是并发，是串行假并发。
- 给每个请求单独设超时：
ctx, cancel := context.WithTimeout(ctx, 8*time.Second)，然后传给client.Do(req.WithContext(ctx)) - 禁用重定向：
CheckRedirect: func(req *http.Request, via []*http.Request) error { return http.ErrUseLastResponse }，否则 302 可能跳到未知深度，打乱你的深度计数 - 别复用
http.Transport的连接池到极致；设MaxIdleConnsPerHost: 20，太高会导致深层请求抢不到连接
用 select + time.After 控制 DFS 深度等待，真的靠谱吗？
不靠谱。很多人想“等当前深度全部完成再进下一层”，于是写 select { case ——这只会制造竞态：时间到了就切层，不管有没有漏掉的子页面；或者永远等不到 doneCh，直接卡死。
立即学习“go语言免费学习笔记（深入）”；
- 真正可控的方式是：用
sync.WaitGroup记录「本层已派发任务数」和「本层已完成数」，完成数 == 派发数时才推进下一层 - WaitGroup 必须在 goroutine 启动前 Add，在 defer 里 Done；Add 放错位置（比如放循环外）会导致
panic: sync: negative WaitGroup counter - 如果某层 URL 数为 0（比如首页没链接），别等，直接退出；否则
WaitGroup.Wait()会永久阻塞
DFS 并发最难的不是发请求，是让“深度”这个逻辑概念在异步环境中不漂移——它要求你放弃调用栈直觉，老老实实用显式状态（深度标记、计数器、队列分层）去锚定每一层的行为边界。
