http.Client 默认复用连接导致IP切换失效，因连接池复用旧TCP连接；需禁用复用、新建Client或Transport，并动态管理代理池与熔断限流。
为什么 http.Client 默认复用连接会导致 IP 切换失效
很多开发者以为只要每次请求前换掉 http.Transport.DialContext 里的代理地址，IP 就能实时切换。但实际中常发现：连续请求仍从同一个出口 IP 发出。根本原因是 http.Client 默认启用连接池，复用底层 TCP 连接 —— 即使你改了代理配置，旧连接仍走原路径。
实操建议：
- 必须显式禁用连接复用：
Transport.MaxIdleConns和MaxIdleConnsPerHost设为0 - 每次请求前新建独立的
http.Client实例（轻量，无性能瓶颈）或至少新建http.Transport - 若用代理链（如 socks5 + http），确保
Transport.Proxy返回的 URL 每次都不同，且不被缓存
如何安全地在 goroutine 中轮换动态代理 IP
常见错误是把代理列表存在全局变量里，多个 goroutine 并发读写导致竞态，或误用 rand.Intn 在无 seed 下总返回相同值。更隐蔽的问题是：代理 IP 可能突然失效，但你的爬虫还在持续往它上面发请求。
实操建议：
- 用带超时的 channel 分发代理（例如
chan string），由单独 goroutine 负责探测、剔除失效 IP 并补充新 IP - 每次取代理时加
select+time.After防卡死，避免因代理池空导致整个 worker 阻塞 - 不要直接用
math/rand，改用crypto/rand生成种子，或用time.Now().UnixNano()初始化rand.New - 示例片段：
proxy := <-proxyCh client := &http.Client{ Transport: &http.Transport{ Proxy: http.ProxyURL(&url.URL{Scheme: "http", Host: proxy}), // ... 其他配置 }, }
遇到 net/http: request canceled (Client.Timeout exceeded) 时怎么定位是 IP 还是目标站问题
这个错误表面看是超时，但背后可能是代理响应慢、目标站主动限速、或 TLS 握手被干扰。尤其用廉价动态住宅代理时，大量 IP 会被 Cloudflare 或 Akamai 标记为可疑，触发 JS 挑战或 403，而 Go 的 http.Client 默认不执行 JS，直接卡在 TLS 层或返回空响应。
实操建议：
- 开启
http.Transport.TLSHandshakeTimeout和http.Transport.ResponseHeaderTimeout，分别设为 5s 和 8s，比总超时更细粒度 - 捕获
url.Error并检查Err字段是否为*net.OpError，再判断是dial失败（代理层）还是read失败（目标站拦截） - 对高频失败的代理 IP，记录其失败类型（timeout / tls / status=403）并加入黑名单，避免 1 分钟内重复使用
为什么用 context.WithTimeout 控制单个请求还不够
单个请求超时只能防止某次卡死，但分布式场景下更危险的是“雪崩”：一个代理节点延迟升高 → 所有 goroutine 等待 → 新请求不断堆积 → 内存暴涨 → 整个进程 OOM。这时需要跨请求维度的节流与熔断。
实操建议：
- 用
golang.org/x/time/rate.Limiter对每个代理 IP 单独限速（不是全局），例如每秒最多 2 个请求 - 对每个代理维护一个简易状态机：idle → probing（发 HEAD）→ active → degraded（失败率 >30%）→ banned（暂停 5 分钟）
- 避免在 defer 中调用
http.Response.Body.Close()后再读取 body，否则可能 panic；应先读完再 close，或用io.Copy(ioutil.Discard, resp.Body)快速释放
