requests默认自动跟随重定向，需设allow_redirects=False手动控制；此时响应含Location头而非HTML内容，可用r.is_redirect判断跳转，且Session不支持全局设置该参数。
requests 默认会自动跟随重定向，但有时你得关掉它
默认情况下，requests.get() 或 requests.post() 会自动处理 301/302 等重定向响应，并返回最终页面的内容。这看起来省事，但实际开发中常出问题：比如你想检查是否被跳转、获取跳转链、或避免登录后被重定向到首页而漏掉关键响应头。
关键点是：allow_redirects 参数控制这个行为，默认为 True。设为 False 后，请求会在收到第一个 30x 响应时就停下，返回那个跳转响应本身。
- 想看原始跳转地址？用
r.headers.get("Location")提取跳转目标 - 需要手动控制跳转逻辑（比如只跳一次、跳到特定域名）？必须关掉自动跳转
- 某些 API 文档明确要求“禁止自动重定向”，否则签名验证失败——这是真实踩坑点
怎么判断请求到底有没有被重定向
不能光看 r.status_code 是不是 200。如果 allow_redirects=True（默认），即使原始响应是 302，r.status_code 也会是最终页面的 200；只有关掉自动跳转，才能拿到真实的跳转状态码。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 调试阶段加一句
print(r.status_code, r.url)，对比请求 URL 和r.url是否一致 - 检查
r.is_redirect属性（布尔值），它比查状态码更可靠 - 如果
r.is_redirect为True且allow_redirects=False，说明你成功捕获了跳转响应
allow_redirects=False 时，response 的内容不是 HTML
很多人关掉自动跳转后，还试图用 r.text 解析 HTML，结果报错或拿到空内容。因为 302 响应体通常为空，或只含简单提示文本，没有结构化 HTML。
此时真正有用的是响应头：
-
r.headers.get("Location")—— 必读，跳转目标 URL -
r.headers.get("Set-Cookie")—— 登录跳转时可能带新 Cookie，漏掉会导致后续请求未授权 -
r.headers.get("X-Redirect-Reason")（某些服务自定义）—— 可能说明跳转原因
别解析 r.text，它基本没信息量。
Session 对象里 allow_redirects 的行为容易混淆
requests.Session() 实例发起请求时，allow_redirects 依然以单次请求参数为准，不会继承 Session 级别的设置。也就是说，session.get(url, allow_redirects=False) 才生效，session.allow_redirects = False 是无效写法，requests 根本不认这个属性。
常见误操作：
- 以为设置了
session.trust_env = False就能影响重定向——其实无关 - 在
session.mount()里配 adapter 想控制跳转——adapter 不处理重定向逻辑 - 用
session.request(method, url, allow_redirects=False)却忘了传method，导致调用失败
重定向控制粒度很细，只存在于每次 .get() / .post() 调用里，没捷径可抄。
