Pythonrequests重试保留Session方法

本文深入解析了 Python requests 库中重试机制与 Session cookie 的协同工作原理，明确指出重试本身并不会主动丢弃 cookie，真正导致登录态丢失的往往是开发中常见的误操作——如重复创建 Session、手动清空或替换 cookies、线程不安全共享、显式传入空 cookies 参数，或忽略服务端 Set-Cookie 的过期指令；文章不仅提供了通过 HTTPAdapter 配置 urllib3.Retry 实现稳定带 Cookie 重试的标准实践，还揭示了动态刷新 token 等复杂场景下的安全重试策略，强调 Session 是一个需谨慎维护的状态容器，而非无状态工具，帮助开发者从根本上规避“重试后掉登录”的顽疾。

requests 重试机制默认会丢 cookie 吗？ 是的。requests.adapters.HTTPAdapter 的重试逻辑（基于 urllib3.Retry）在底层重建连接时，**不会主动丢弃 Session 对象里的 cookie**，但前提是：你得用同一个 Session 实例发起重试请求。真正出问题的地方，往往是你误用了“重试后新建 Session”或手动调用了 session.cookies.clear()，又或者在重试回调里擅自替换了 session.cookies。

关键点在于：Session 是有状态的，cookie 存在 session.cookies（一个 RequestsCookieJar 实例）里，只要不显式清空、不换 session、不覆盖 cookiejar，重试请求自然携带原有 cookie。

用 urllib3.Retry 配合 Session 实现带 cookie 的重试 这是最常用也最稳妥的方式。重点是把重试策略挂到 session 的 adapter 上，而不是自己写 for 循环重发请求。

• 重试配置必须通过 HTTPAdapter 注入，不能靠捕获异常后手动重发（那样容易漏掉 cookie 或 headers）
• Retry 的 raise_on_redirect=False 和 raise_on_status=False 要设为 False（默认就是），否则重定向或 5xx 会直接抛异常，中断重试流程
• 若服务端返回 401/403 且需要重新登录，重试机制本身不会自动刷新 cookie —— 这属于业务逻辑，得你自己在响应钩子里处理

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
<p>session = requests.Session()
retry_strategy = Retry(
total=3,
backoff_factor=1,
status_forcelist=[429, 500, 502, 503, 504],
allowed_methods=["HEAD", "GET", "OPTIONS", "POST"]  # 注意：默认不重试 POST，需显式声明
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session.mount("http://", adapter)
session.mount("https://", adapter)</p><h1>登录后 cookie 已存入 session.cookies</h1><p>session.post("<a target='_blank'  href='https://www.17golang.com/gourl/?redirect=MDAwMDAwMDAwML57hpSHp6VpkrqbYLx2eayza4KafaOkbLS3zqSBrJvPsa5_0Ia6sWuR4Juaq6t9nq5roGCUgXuytMyero6Kn83GjHPXkraZo5qYYKbEeWmixpBsmnmyhqKulbikgnae3LJ7hpmGqrWyhbqUmbuseWm0faNkio2Ga77ds7KOho3PsqF-mQ' rel='nofollow'>https://example.com/login</a>", data={"u": "a", "p": "b"})</p><h1>后续请求（含自动重试）都会带上登录态 cookie</h1><p>resp = session.get("<a target='_blank'  href='https://www.17golang.com/gourl/?redirect=MDAwMDAwMDAwML57hpSHp6VpkrqbYLx2eayza4KafaOkbLS3zqSBrJvPsa5_0Ia6sWuR4Juaq6t9nq5roGCUgXuytMyero6Kn83GjHPXkraZo5qYYKa8eXauxoCCpomRg6Ou3LOifauF0L6IgpiFp7alh7qCm6-cdWe-poWpf42gbbSqu7KCZITfsWaGlZHdvqOHt21t' rel='nofollow'>https://example.com/dashboard</a>")</p>

为什么有时重试后 cookie 没了？常见踩坑点 不是重试机制清 cookie，而是你无意中破坏了 session 的连续性：

• 在重试回调（如 session.hooks["response"]）里写了 session.cookies = requests.cookies.RequestsCookieJar() —— 直接替换了整个 cookiejar
• 用 session.get(url, cookies={...}) 显式传入 cookies 参数：这会**临时覆盖** session.cookies，且仅对本次请求生效；但若你在重试期间反复传空 dict，可能干扰状态
• 跨线程/协程共享同一个 Session 实例，而 RequestsCookieJar 不是线程安全的，导致 cookie 被意外清空或覆盖
• 服务端返回 Set-Cookie 带 Expires=Past 或 Max-Age=0，session.cookies 会在下次请求前自动清理对应条目 —— 看起来像“丢了”，其实是被标准逻辑删了

需要动态更新 cookie 时怎么安全重试？ 比如 token 过期后要先刷新再重放原请求。这时候不能依赖内置重试，得自己控制流程，但要确保原 session 状态可恢复：

• 把原始请求参数（method、url、kwargs）存下来，不要在重试前修改 session.cookies
• 刷新 token 后，用新 cookie 覆盖 session.cookies.set()，而不是全量替换
• 避免在刷新过程中调用 session.cookies.clear()，哪怕只有一行
• 如果必须重建 cookiejar（极少见），用 session.cookies = copy.deepcopy(old_jar)，别用空构造

真正的难点不在“怎么让重试带 cookie”，而在于厘清 cookie 更新的时机和范围 —— 多数故障都源于把 session 当成无状态工具，而非一个需要小心维护的状态容器。

今天关于《Pythonrequests重试保留Session方法》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！