必须从请求层拆解防御逻辑，而非仅加ua：需动态切换真实设备ua并补全sec-ch-ua等头、代理需连通性探测与缓存、cookie管理须用colly修复domain匹配缺陷、限流应按域名用rate.limiter协同控制。
http.Client 默认配置跑不赢反爬，不是“加个 UA 就能过”，而是必须从请求层拆解防御逻辑。
为什么固定 User-Agent 会被秒封
目标网站的 WAF（比如 Cloudflare）根本不需要等你发完 10 个请求——只要连续两个请求的 User-Agent 完全一致，且没带 Sec-Ch-Ua、Accept-Language 等 Chromium 必备头，就直接进风控队列。
常见错误现象：
- 把 req.Header.Set("User-Agent", fixedUA) 写在 client 初始化里，所有请求共用一个字符串
- UA 字符串里含未转义的括号或空格，导致 HTTP 头解析失败，服务端收到空 UA
- 只换 UA 不换 Referer，比如用 iPhone UA 却把 Referer 设成 desktop 页面
正确做法是每次构造 *http.Request 前动态取值：
- 用真实设备 UA 列表（Windows/macOS/iOS/Android 各至少两条）
- 配合
rand.Intn(len(userAgents))随机索引，别用rand.Seed()重复初始化 - 同时补全
Accept、Accept-Language、Sec-Ch-Ua（值要和 UA 版本匹配）
http.Transport 代理轮换不能只靠 http.ProxyURL
http.Transport 的 Proxy 字段只负责转发，不校验代理可用性、不处理认证、不自动重试失效节点。
实际踩坑点：
- 代理 URL 缺 http:// 前缀，url.Parse() 返回 nil 导致 panic
- 带账号密码的代理（如 http://user:pass@1.2.3.4:8080），标准库不会自动加 Proxy-Authorization 头
- 某个代理超时或返回 407 Proxy Authentication Required，后续请求仍被分发过去
建议封装一个代理获取函数：
- 先用
http.Get对代理做连通性探测（超时设为 3 秒） - 成功后缓存该代理 30 秒，避免频繁探测
- 失败则从池中剔除，并触发告警日志
Cookie 管理为什么不能只用 cookiejar.New(nil)
标准库 net/http/cookiejar 对 Domain 和 Path 匹配逻辑过于宽松，遇到 Set-Cookie: domain=.example.com; SameSite=Strict 这类策略会静默丢弃。
典型问题：
- 第一次访问登录页拿到 cf_clearance，但因 domain 解析失败没存进去
- 后续请求没带该 cookie，直接被 Cloudflare 拦截回验证码页
- 多域名场景下 cookie 错乱（比如 a.example.com 的 cookie 被发到 b.example.com）
推荐方案：
- 用
colly自带的CookieJar，它修复了 net/http/cookiejar 的 domain 匹配缺陷 - 首次请求前手动注入可信 cookie：
c.SetCookies(targetURL, cookies) - 检查响应 header 中是否有
Set-Cookie带Secure标记，确认 transport 是否启用了 TLS
限流为什么不能只靠 time.Sleep
time.Sleep(2 * time.Second) 控制的是“发起间隔”，但真实请求耗时由 DNS、TLS 握手、服务端排队共同决定。你 sleep 2 秒，实际间隔可能达 10 秒，反而触发“低频慢速攻击”检测。
更可靠的做法是：
- 按域名维度创建独立 rate.Limiter：rate.NewLimiter(rate.Every(2*time.Second), 1)
- 在 client.Do() 调用前执行 limiter.Wait(ctx)
- 并发 goroutine 共享同一个 limiter 实例，避免每个协程各自 sleep
真正难的不是写对某一行代码，而是让所有环节——UA、Referer、Header、Transport、Cookie、限流——协同不露破绽。漏掉任何一个，都可能让整个请求链路在第三步就卡死。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
