requests无法执行js，故无法获取动态生成的加密cookie；playwright可模拟真实浏览器环境并可靠提取完整cookie，但需正确等待js执行完成、使用context.cookies()读取，并用add_dict_to_cookiejar注入requests。
为什么不能直接用 requests 执行 JS 获取加密 Cookie
requests 本身不解析 JavaScript，遇到 document.cookie 被动态生成、或依赖 window.crypto/atob/eval 等浏览器环境的逻辑时，requests.get() 拿到的只是初始空 Cookie 或服务端硬编码的默认值。你看到的“加密 Cookie”大概率是前端 JS 运行后才写入的，比如 __jsl_clearance_s、__ddg1_ 或某风控系统生成的 token。
用 Playwright 同步执行 JS 并提取 Cookie 最可靠
Playwright 是目前最接近真实浏览器行为的方案，支持完整 DOM + JS 执行上下文，且能自动等待页面加载、JS 执行完成。关键不是“执行 JS”，而是确保 JS 已生效、Cookie 已写入、再读取。
- 必须等 JS 完成执行：用
page.wait_for_function("document.cookie.includes('your_target_key')")，而不是简单time.sleep(2) - 读取方式要用
page.context.cookies()，不是page.evaluate("document.cookie")—— 后者只返回当前 document 可见的 Cookie（可能被 HttpOnly 拦截） - 启动时加
headless=False初次调试，确认目标 Cookie 确实出现在 DevTools → Application → Cookies 中 - 若目标站点校验 User-Agent 或 navigator，需在 launch 时传
user_agent和args=["--disable-blink-features=AutomationControlled"]
PyExecJS 不适合现代加密 Cookie 场景
execjs 库只能运行纯 JS 字符串，无法模拟 window、document、navigator 等浏览器全局对象，更不支持 crypto.subtle.digest() 或 WebAssembly。遇到如下代码会直接报错：
const encoder = new TextEncoder();
const hash = await crypto.subtle.digest('SHA-256', encoder.encode(input));
即使强行 patch window 对象，也无法绕过 TLS 指纹、Canvas 指纹、WebGL 参数等反自动化检测点 —— 这些根本不在 JS 引擎层面，而在浏览器实例里。
拿到 Cookie 后别直接复用到 requests
从 Playwright 获取的 context.cookies() 返回的是字典列表，含 name、value、domain、path、expires 等字段。但 requests.Session().cookies.set() 只认 name 和 value，其他字段会被忽略，导致：
- Domain 不匹配 → 请求时 Cookie 不被发送
- Secure=True 但用 HTTP 请求 → 浏览器/requests 主动丢弃
- Expires 已过期 → 即使设了也无效
正确做法是用 requests.utils.add_dict_to_cookiejar(session.cookies, {cookie_dict})，或手动构造 requests.cookies.RequestsCookieJar() 并调用 set() 时传全字段。
真正难的不是“怎么执行 JS”，而是判断哪段 JS 生成了你要的 Cookie、它依赖哪些浏览器 API、是否被混淆或懒加载、以及后续请求是否还需携带 Referer / X-Requested-With 等配套头信息 —— 这些都得靠抓包 + 断点调试定位，没法靠通用代码覆盖。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
