go中http.client需显式配置cookiejar.new(nil)并复用实例，禁用自动重定向以捕获set-cookie，签到前校验referer和user-agent，并通过健康检查判断session有效性。
Go 中用 http.Client 自动维护 Cookie 最省事
手动拼接、解析、存储 Cookie 字符串是自找麻烦。Go 标准库的 http.Client 默认自带 CookieJar，只要初始化时给它配一个，后续所有请求自动带 Cookie，登录态自然延续。
常见错误是直接用 http.Get 或新建无配置的 http.Client，结果每次请求都是“新游客”，根本拿不到登录后的页面。
- 必须显式创建
http.Client并设置Jar字段，不能依赖默认零值客户端 - 推荐用
cookiejar.New(nil)初始化（nil表示不设策略限制，适合简单签到场景） - 整个脚本生命周期内复用同一个
http.Client实例，否则 Cookie Jar 不生效
jar, _ := cookiejar.New(nil)
client := &http.Client{Jar: jar}
// 后续 client.Do(req) 会自动读写 Cookie
登录接口返回 302 或 200 但没跳转？检查 Location 头和重定向策略
很多网站登录后返回 302 Found 并带 Location 头跳转到主页，而 Go 的 http.Client 默认自动跟随重定向——这看似方便，实则埋雷：跳转过程中的中间响应（比如带关键 Set-Cookie 的登录响应）会被吞掉，导致 Cookie 丢失。
典型现象：登录请求看似成功，但后续访问个人页返回 401 或跳回登录页。
立即学习“go语言免费学习笔记（深入）”；
- 把
CheckRedirect设为func(req *http.Request, via []*http.Request) error { return http.ErrUseLastResponse }，强制停在登录响应这一步 - 手动检查响应状态码是否为
200或302，再读取resp.Header["Set-Cookie"]确认 Cookie 已写入 Jar - 不要依赖“登录请求返回 200 就算成功”，有些接口只返回空
200，真正登录态靠后续 Set-Cookie
签到请求发出去却提示“未登录”？大概率是 Referer 或 User-Agent 被过滤
不少网站签到接口有反爬逻辑，不校验 Cookie 本身，而是看请求头里 Referer 是否来自登录后的首页，或 User-Agent 是否过于简陋（比如空值或默认值）。
错误表现：Cookie 明明存在，client.Jar.Cookies(u) 也能打印出来，但签到接口返回 “请先登录”。
- 签到前，用同一
client先 GET 一次首页（如/dashboard），确保 Referer 链路完整 - 给所有请求显式设置
req.Header.Set("User-Agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36") - 签到请求的
req.Header.Set("Referer", "https://example.com/dashboard")必须匹配你刚访问过的页面 URL
Session 过期时间短、脚本跑几天就失效？别硬扛，加个简单健康检查
自动签到脚本最常崩在“某天突然不工作”，查日志发现 Cookie 没变，但响应内容变成登录页 HTML。本质是服务端 Session 过期（比如 7 天无操作清空），而本地 Cookie Jar 还留着旧 Cookie。
不建议定时刷新 Cookie 或搞复杂心跳，简单有效的方式是：每次签到前，先 GET 一个已登录才能看到的接口（如用户信息 API），用响应体或状态码判断是否仍在线。
- 检查响应 HTTP 状态码是否为
200，且响应 JSON 中有"user_id"字段（或其他业务标识） - 如果失败，立刻走完整登录流程（账号密码 POST → 提取新 Cookie → 再签到），而不是重试签到
- 避免在登录逻辑里硬编码表单字段名，有些网站会动态改
name="csrf_token"的 key，优先从登录页 HTML 中regexp提取
Session 和 Cookie 不是黑盒，它们只是 HTTP 头里的字符串。问题出在哪，就盯哪一行响应头、哪一次请求顺序。多打两次 fmt.Printf("%+v", resp.Header) 比猜强得多。
