直接硬编码cookie会失效,因动态cookie(如sessionid、__jsluid_s)需js执行或服务端set-cookie生成;requests.session()可自动管理cookie,但js生成的需selenium等方案提取。

为什么直接硬编码 Cookie 会失效
目标网站的 Cookie 很少是静态的,尤其是带 sessionid、_token、__jsluid_s 这类字段的,通常由前端 JS 运行后生成,或依赖上一步登录/访问响应头中的 Set-Cookie。硬写一个过期的 Cookie 字符串,发请求时大概率返回 403 或跳转到登录页。
用 requests.Session() 自动管理 Set-Cookie
绝大多数需要动态 Cookie 的场景,其实只需要让会话自动接收并携带服务端下发的 Cookie —— 这正是 requests.Session() 的默认行为。
- 首次 GET 主页或登录页,服务端通过响应头
Set-Cookie种下初始 Cookie(如__cf_bm、PHPSESSID) - 后续所有
session.get()/session.post()请求会自动带上这些 Cookie - 无需手动提取
headers['Cookie']字符串,更不要拼接"a=1; b=2"
示例:
import requests
session = requests.Session()
session.get("https://example.com/login") # 触发 Set-Cookie
session.post("https://example.com/auth", data={"u": "x", "p": "y"}) # 自动携带上一步 Cookie
遇到 JS 生成 Cookie(如 __jsluid_s、__jsl_clearance)怎么办
这类 Cookie 由页面内 JS 执行后写入 document.cookie,requests 无法执行 JS,必须换方案。
- 优先尝试用
selenium或playwright启动真实浏览器,等 JS 执行完再取driver.get_cookies() - 若只需模拟逻辑,可反编译目标 JS(常见于
__jsl_clearance),提取算法后用 Python 复现(注意:部分含时间戳、RSA 签名、WebAssembly 调用,复现成本高) - 临时绕过:有些站点只校验 Cookie 是否存在,不校验值,可先用浏览器打开一次,手动复制当前有效的
Cookie字符串,设为session.cookies.set()(仅限调试,不可长期用)
示例(selenium 提取):
from selenium import webdriver
driver = webdriver.Chrome()
driver.get("https://example.com")
cookies = driver.get_cookies() # 返回字典列表
for c in cookies:
session.cookies.set(c['name'], c['value'], domain=c['domain'])
手动设置 Cookie 时最容易错的三件事
即使你决定手动塞 Cookie,也得避开这几个坑:
- 误把整个
Cookie字符串(如"a=1; b=2")直接塞进headers—— 正确做法是用session.cookies.set('a', '1'),让 requests 自动组装 - 忽略
domain和path参数,导致 Cookie 不被发送 —— 比如目标接口是https://api.example.com/v1,但你设的 Cookie domain 是.example.com,而实际需要api.example.com - 时间相关的 Cookie(如
expires)过期了没更新 —— 可用session.cookies.set(..., expires=time.time()+3600)显式控制
真正难的不是“怎么设”,而是“从哪来”——JS 渲染、加密校验、滑块/验证码联动的 Cookie,往往意味着你该重新评估是否值得爬,或者换合作方式。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











