goroutine泄漏导致爬虫oom，主因是http请求后未读取响应体并关闭resp.body，致使连接池阻塞；务必每次调用http.do或http.get后显式调用resp.body.close()。
goroutine 泄漏导致爬虫内存暴涨
并发爬虫跑着跑着就 OOM，八成不是数据量大，是 goroutine 没收干净。常见于用 http.Get 发请求后，没读完响应体就直接 return，底层连接池会卡住，后续所有依赖该连接的 goroutine 都悬着。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每次调用
http.Do或http.Get后，必须显式调用resp.Body.Close()，哪怕你只取状态码 - 别在
select里丢掉case 分支——超时或取消时，要同步停止发请求、关闭管道、回收 goroutine - 用
pprof快速验证：访问/debug/pprof/goroutine?debug=2，看是不是大量net/http.(*persistConn).readLoop卡在 waiting
限速控制不能只靠 time.Sleep
time.Sleep 在高并发下既不准又浪费资源：100 个 goroutine 同时 sleep 100ms，实际可能有 99 个在空等，CPU 毛刺高，还压不住 QPS。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
rate.Limiter（来自golang.org/x/time/rate），它基于 token bucket，支持突发和匀速两种模式 - 初始化时别写死
rate.Every(100 * time.Millisecond)——这个等价于每秒 10 次，但没考虑突发；更稳妥的是rate.NewLimiter(rate.Limit(10), 3)，允许最多 3 次突发 - 在真正发请求前调用
limiter.Wait(ctx)，而不是sleep后再发——这样能自然融入上下文取消逻辑
URL 去重和任务分发容易踩 map 并发写 panic
多个 goroutine 同时往一个 map[string]bool 里写已抓取 URL，不出几秒就 fatal error: concurrent map writes。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别手写带锁 map，直接用
sync.Map存已访问 URL，读多写少场景下性能不差 - 更推荐把去重逻辑前置：用
chan string做任务队列，由单个 goroutine 消费、查重、去重后再派发，避免下游重复判断 - 如果要用布隆过滤器（比如
github.com/yourbasic/bloom），注意它不支持并发写，得包一层sync.Mutex
HTTP 客户端复用与超时设置不对，连接池打满
每个请求都 new 一个 http.Client，很快就会报 dial tcp: lookup xxx: no such host 或 too many open files——其实是底层连接没复用，文件描述符耗尽。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 全局复用一个
http.Client实例，设置Transport的MaxIdleConns和MaxIdleConnsPerHost，例如都设为 100 - 必须设
Timeout、IdleConnTimeout、TLSHandshakeTimeout，否则 DNS 卡住或服务端不响应时，连接永远挂在那里 - 别信默认值：
http.DefaultClient的Timeout是 0（无限等待），生产环境必须覆盖
真正难的不是启动一堆 goroutine，而是让它们在错误、超时、取消、重试之间自然退场。连接没关、令牌没取、管道没关、context 没传到底——这些地方漏一个，爬虫跑一天就变僵尸进程。