不会丢cookie，前提是复用同一Session实例；requests重试机制本身不主动清除session.cookies，常见丢失源于误新建Session、手动清空cookies或线程不安全操作。
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
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)
登录后 cookie 已存入 session.cookies
session.post("https://www.php.cn/link/d9976f1c2c0c972d1cee0c3647cbd194", data={"u": "a", "p": "b"})
后续请求（含自动重试）都会带上登录态 cookie
resp = session.get("https://www.php.cn/link/fad68ee497f1cf9108b630e7ce630e6c")
为什么有时重试后 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)，别用空构造
HTTPAdapter 注入，不能靠捕获异常后手动重发（那样容易漏掉 cookie 或 headers）Retry 的 raise_on_redirect=False 和 raise_on_status=False 要设为 False（默认就是），否则重定向或 5xx 会直接抛异常，中断重试流程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)
登录后 cookie 已存入 session.cookies
session.post("https://www.php.cn/link/d9976f1c2c0c972d1cee0c3647cbd194", data={"u": "a", "p": "b"})
后续请求（含自动重试）都会带上登录态 cookie
resp = session.get("https://www.php.cn/link/fad68ee497f1cf9108b630e7ce630e6c")
- 在重试回调（如
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)，别用空构造
session.cookies
session.cookies.set()，而不是全量替换session.cookies.clear()，哪怕只有一行session.cookies = copy.deepcopy(old_jar)，别用空构造真正的难点不在“怎么让重试带 cookie”，而在于厘清 cookie 更新的时机和范围 —— 多数故障都源于把 session 当成无状态工具，而非一个需要小心维护的状态容器。
立即学习“Python免费学习笔记（深入）”；
