goroutine泄漏、http客户端未复用、错误处理不落地是并发爬虫三大核心问题：需用信号量或缓冲channel限并发，全局复用并配置http.client，区分错误类型实现精准重试。
goroutine 泄漏：不加控制地起 goroutine 必崩
并发爬虫最常踩的坑不是性能差，而是程序跑着跑着内存爆了、CPU 拉满、最后 panic: runtime: out of memory。根本原因是没限制并发数，每个 URL 都 go fetch(url)，几千个 URL 就起几千个 goroutine，而 HTTP 客户端连接、DNS 解析、TLS 握手全在背后排队堆积。
实操建议：
- 永远不用裸写
go fetch(url)，必须套进池里——用semaphore.NewWeighted(n)（golang.org/x/sync/semaphore）或带缓冲的 channel 做并发闸门 - 哪怕只设
n = 10，也能把 goroutine 数压到两位数，同时避免目标站封 IP 或触发限流 - 别信“goroutine 很轻”，它默认栈 2KB，上万 goroutine 光栈就吃掉 20MB+，加上 net/http 的连接池和 TLS 状态，实际开销远超预期
HTTP 客户端复用：不重用 http.Client 就是自找超时和连接耗尽
每次请求都 new 一个 http.Client，会反复创建底层 http.Transport，导致连接无法复用、DNS 缓存失效、TLS 会话不复用，最终表现是大量 context deadline exceeded 或 dial tcp: lookup failed。
实操建议：
- 全局复用一个
*http.Client，设置合理的Timeout、IdleConnTimeout和MaxIdleConnsPerHost - 例如：
client := &http.Client{Timeout: 10 * time.Second}，再配Transport时设MaxIdleConnsPerHost: 100，否则默认 2，连 3 个 URL 就卡住 - 别在 goroutine 里改
client.Timeout—— 它不是并发安全的；要差异化超时，用ctx.WithTimeout()传进client.Do(req.WithContext(ctx))
错误处理不落地：忽略 io.EOF、net.ErrClosed 和重试逻辑
真实网络环境里，resp, err := client.Do(req) 失败太常见：DNS 挂了、对方关了连接、中间代理截断、甚至 TLS 版本不匹配。但很多人只判 err != nil 就跳过，结果丢掉大量可恢复请求。
实操建议：
- 区分错误类型：对
url.Error看Err字段，net.OpError判Timeout()，net.ErrClosed可重试，http.ErrUseLastResponse要手动读resp.Body - 简单重试用
for i := 0; i + <code>time.Sleep(100 * time.Millisecond)，别用指数退避搞复杂——爬虫不是金融交易系统 - 务必
defer resp.Body.Close()，否则连接永远不归还给连接池，MaxIdleConnsPerHost形同虚设
响应体读取不完整：不读完 resp.Body 就丢弃，连接池直接瘫痪
写 if resp.StatusCode == 200 { parse(resp.Body) } 然后不管 else 分支，或者解析出错就 return，会导致 resp.Body 没被读完或没关闭。后果是：该连接卡在 idle 状态，后续请求拿不到新连接，Client 最终阻塞在 transport.roundTrip。
实操建议：
- 无论成功失败，都要确保
resp.Body被读完或关闭。最稳妥是io.Copy(io.Discard, resp.Body)再Close() - 如果只想要状态码和 header，用
resp, err := client.Head(url)，它不传 body，省带宽也省连接 - 别用
strings.NewReader(string(body))二次解析——body是io.ReadCloser，转 string 会吃光内存，大页面直接 OOM
真正难的不是并发模型，是 HTTP 协议细节在高并发下的连锁反应。比如一个没关的 Body，可能让整个连接池在 5 分钟后才超时释放——而这 5 分钟里，你还在不断起新的 goroutine。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
