限流是关键，需用带缓冲的channel模拟信号量控制并发数，避免内存暴涨、IP被封、DNS耗尽等问题，核心在于可控并发而非无节制启动goroutine。
用 goroutine + channel 控制并发数，别直接起成百上千个
无节制启 goroutine 是最常见错误：内存暴涨、被目标站封 IP、DNS 耗尽。必须限流。核心不是“能并发”，而是“可控并发”。semaphore 本质就是带缓冲的 chan struct{}，每发一个请求前先 ，完成后 <code>sem 。
- 缓冲大小即最大并发数，比如
sem := make(chan struct{}, 10)表示最多同时 10 个请求 - 所有请求逻辑必须包裹在
func() { 中，否则漏释放会卡死 - 别用
time.Sleep模拟限速——它不释放 goroutine，只是挂起；真限速要用time.Ticker配合 channel
http.Client 必须复用，且设置超时和连接池
每次 new http.Client 会新建底层 Transport，导致 TCP 连接无法复用、TIME_WAIT 爆满、DNS 查询重复。默认 client 的 DefaultTransport 虽然有连接池，但参数极保守（MaxIdleConns=100），爬虫场景下远远不够。
- 显式构造
http.Client，并配置Transport：MaxIdleConns和MaxIdleConnsPerHost建议设为 200~500 - 必须设
Timeout（总超时）、IdleConnTimeout（空闲连接保持时间）、TLSHandshakeTimeout，否则慢响应或 TLS 卡住会拖垮整个池 - 如果目标站支持 HTTP/2，确保 Go 版本 ≥1.6 且服务端开启，能显著降低连接开销
URL 去重和任务分发用 map[string]struct{} + sync.Map，别用全局锁
爬虫最耗时的不是网络，是重复请求和锁竞争。用 map[string]struct{} 存已抓 URL 是最小开销方案（struct{} 零字节），但普通 map 不支持并发读写。
- 高频写入场景（如解析出大量新链接）用
sync.Map，注意它的LoadOrStore返回值是value, loaded bool，要靠loaded判断是否已存在 - 不要把去重逻辑塞进主 goroutine；把新发现的 URL 发到一个专用去重 channel，由单个 goroutine 统一处理并分发给 worker
- 如果需要持久化去重（重启不丢），改用
bolt或badger，但会引入 IO 延迟，需权衡
错误处理不能只打日志，要区分可重试与不可重试
net/http 错误类型杂乱：DNS 失败、连接拒绝、TLS 握手超时、HTTP 4xx/5xx、body 读取中断……全丢进重试队列只会让问题恶化。
立即学习“go语言免费学习笔记（深入）”；
- 不可重试：400、401、403、404、410、429（Too Many Requests）、501、505 —— 这些是语义明确的失败，重试无意义
- 可重试：临时性错误如
net.OpError（连接超时、拒绝）、url.Error（timeout、EOF）、500/502/503/504 —— 但建议加退避（exponential backoff），最多重试 2~3 次 - 所有 error 都要记录原始
err.Error()和 URL，否则排查时根本不知道卡在哪一环
真正难的不是并发模型，而是如何让每个请求既快又稳：连接复用是否生效、DNS 缓存有没有穿透、TLS 握手是否被干扰、目标站反爬策略怎么绕过——这些都得靠日志+指标+真实响应体分析，光靠 goroutine 数量解决不了。
