正确使用requests.Session()是关键：必须用session实例调用get/post，而非单独传cookies参数；否则Cookie不自动携带、不解析Set-Cookie、不维护上下文。
requests.Session()没用对，Cookie根本没传出去
最常见的情况是：你写了 requests.get(url, cookies=xxx)，但没用 Session 实例。这种写法每次请求都新建连接，cookies 参数只是临时塞进这次请求头，不参与后续自动携带逻辑，更不会解析服务器返回的 Set-Cookie 来更新状态。
正确做法必须用 session = requests.Session()，然后统一调用 session.get() 或 session.post()。否则哪怕你手动加了 Cookie 字符串，也大概率被服务端忽略——因为缺失了关联的 sessionid、csrf_token 等上下文字段。
- 别手写
headers={"Cookie": "a=b; c=d"}，这绕过了 requests 的 Cookie 管理机制，无法自动处理Domain、Path、Secure等约束 - 检查
session.cookies是否真有值：print(list(session.cookies))，空列表说明登录流程根本没成功存入 - 如果登录后立刻
session.get("/profile")却跳转到登录页，大概率是重定向过程中 Cookie 断掉了（见下一条）
POST 登录后 302 重定向，但目标页仍显示未登录
这是典型的 Cookie 传递断裂。requests 默认 allow_redirects=True，会自动跟进 302，但部分网站在跳转中间页（比如 /login/callback）时会清空 session，或把新 Cookie 设在子域名（如 auth.example.com），而你的请求发向的是 www.example.com，导致 Cookie 不匹配。
解决方法不是关掉重定向，而是拆开看每一步：
立即学习“Python免费学习笔记（深入）”；
- 登录 POST 时显式设
allow_redirects=False，检查响应resp.status_code == 302和resp.headers.get("Location") - 手动发起 GET 请求到跳转地址，并确认该响应中
Set-Cookie是否包含有效字段（如sessionid、auth_token） - 若跳转目标是不同域名，需手动调用
session.cookies.set("sessionid", value, domain=".example.com")强制设置作用域
Cookie 值本身已失效或动态变化
很多网站的 Cookie 不是静态字符串，比如 token=abc123; expires=Wed, 03-Sep-2026 01:00:00 GMT 看似没过期，但服务端可能已吊销该 token；或者 Cookie 中混有时间戳、签名字段（如 _ts=1756894320&_sig=xxxx），几分钟后就作废。
不能只靠本地文件保存 Cookie 并长期复用。必须配合有效性检测：
- 关键请求前先打一个轻量接口（如
/api/v1/user/me），检查resp.json().get("is_authenticated")或状态码是否为200 - 若失败，立刻触发重新登录流程，而不是重试原请求
- 避免用 HTML 特征判断登录态（如找“退出”按钮），CDN 缓存或页面降级可能导致误判
手动加载的 Cookie 文件格式或属性不兼容
从浏览器导出的 Cookie 文件（如 Firefox 的 cookies.sqlite 或 Netscape 格式文本）常含“会话 Cookie”（无 Expires 字段），这类 Cookie 在 requests 中默认被当作已过期处理，加载后实际为空。
要让导出的 Cookie 可用，得做两件事：
- 导出前，在浏览器开发者工具里把会话 Cookie 的
Expires改成未来时间（如 2030 年），再导出为 Netscape 格式，并确保首行是# Netscape HTTP Cookie File - 加载时用
MozillaCookieJar而非默认CookieJar：jar = MozillaCookieJar("cookies.txt")<br>jar.load(ignore_discard=True, ignore_expires=True)，否则会直接过滤掉无过期时间的条目 - 加载后务必调用
session.cookies.update(jar)，而不是session.cookies = jar—— 后者会丢掉 requests 内部的策略对象
真正麻烦的不是 Cookie 加没加，而是它有没有被服务端认可。同一个 Cookie 字符串，在登录页 POST 成功后能用，在隔 5 分钟后 GET 就失效，这种“看似正常实则脆弱”的状态最容易让人反复调试却找不到根因。
