根本原因是重定向时缺失Referer等关键请求头或服务端校验失败，导致cookie未更新或跳转异常；应检查allow_redirects、response.history、手动补全headers，并在JS跳转场景改用Playwright。
页面重载后 session.cookies 丢失怎么办
根本原因不是“重载”本身，而是重定向过程中 requests.Session 默认不保留原始请求头（尤其是 Referer 和自定义 User-Agent），导致目标站点校验失败，触发二次跳转或返回登录页。更常见的是：服务端通过 Set-Cookie 在重定向响应中下发新 cookie，但你的代码没让 session 自动跟进——其实它默认会，除非你手动禁用了 allow_redirects=False。
实操建议：
- 确认没写
session.get(url, allow_redirects=False)，否则重定向链中断，session.cookies不会更新 - 用
response.history检查是否发生了 302/307 跳转，以及跳转次数是否异常（比如循环重定向） - 若目标站依赖
Referer校验，需在每次请求时显式传入：session.get(url, headers={"Referer": "https://example.com/"}) - 避免手动覆盖
session.cookies.set()，优先让requests自动处理Set-Cookie
如何让 requests 模拟浏览器重定向行为
浏览器对重定向是“带上下文”的：保留 cookie、Referer、甚至部分 JS 状态；而 requests 默认只保 cookie 和基础头，不执行 JS，也不记录跳转前的 DOM 状态。所以“模拟”重点不在“重定向动作”，而在补全被丢弃的上下文。
关键点：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
requests.Session默认已启用自动重定向（allow_redirects=True），无需额外设置 - 若重定向后页面内容为空或返回登录页，大概率是缺失
Referer或User-Agent，补上即可 - 某些站点在重定向响应头中返回
Location: javascript:...—— 这种不是 HTTP 重定向，requests无法识别，必须换用selenium或playwright - 检查重定向终点是否为相对路径（如
Location: /auth/callback），确保session能正确拼接 base URL
Session 重用时遇到 302 循环重定向怎么破
典型现象：调用 session.get() 后卡住，response.history 长度持续增长，最终抛出 TooManyRedirects。这不是网络问题，而是服务端检测到会话状态异常（如 cookie 过期、CSRF token 失效、IP 频控）后，强制跳回登录页，而登录页又跳回原地址，形成闭环。
排查步骤：
- 打印
[r.status_code for r in response.history]，确认是否反复出现302 → 200（登录页）→ 302 - 用
curl -v对比真实浏览器请求头，重点看Cookie、Origin、Sec-Fetch-*等字段是否缺失 - 尝试在首次请求前清空 session：
session.cookies.clear()，再手动 set 登录态 cookie（从浏览器复制） - 若依赖前端 JS 生成的参数（如时间戳、sign），
requests无法复现，必须提取逻辑或改用无头浏览器
什么时候必须放弃 requests 改用 Playwright
不是所有“重载刷新”都能靠补请求头解决。当页面重定向由 JS 触发（例如 window.location.href = '...'、history.pushState()、fetch() 后手动跳转），或重定向目标依赖运行时计算（如加密 token、Canvas 指纹、WebGL 渲染结果），requests 就彻底失效。
判断依据很直接：
- 用浏览器开发者工具 Network 面板勾选 “Preserve log”，刷新页面，看重定向是否出现在 XHR/Fetch 选项卡里（而非 Doc 选项卡）
- 禁用 JS 后页面无法完成跳转或显示“请启用 JavaScript”——说明跳转逻辑在 JS 中
- 抓包发现重定向请求携带了动态生成的
X-Signature或_ts参数，且无法从 HTML 中静态提取 - 此时用
playwright.sync_api.sync_playwright().start()启动 Chromium，用page.goto(url, wait_until="networkidle")才能拿到最终渲染页
真正容易被忽略的是：很多开发者以为“加个 delay”或“多试几次 session”就能绕过 JS 跳转，其实只是掩盖了技术边界——该上浏览器的地方，硬扛 HTTP 层只会越调越迷。
