JavaScript动态Cookie反爬本质是利用浏览器执行环境不可替代性区分人机：服务器要求客户端现场生成含环境指纹、时效性的动态Cookie（如__cf_bm），爬虫若无法执行JS则无法获取该凭证；校验时后端复现前端算法验证签名一致性，传统HTTP库因不支持JS执行而失效。
JavaScript 中 Cookie 的校验，本质是利用浏览器执行环境的不可替代性来区分人与机器。服务器不直接信任请求头里带的 Cookie，而是要求客户端先“现场生成”一个动态、有时效、带环境指纹的 Cookie，再用它发起后续请求——爬虫若无法真实执行 JS，就拿不到这个关键凭证。
动态 Cookie 的生成逻辑
典型流程中，用户首次访问页面时，服务器返回 HTML 并嵌入一段 JS 脚本。这段脚本在浏览器中运行，完成三件事：
- 检测运行环境（如 navigator.webdriver 是否为 false、plugins 是否存在、userAgent 是否完整）
- 采集上下文参数（当前时间戳、页面 URL、已有静态 Cookie、随机 salt 等）
- 通过加密函数（如 SHA256 + 时间戳混淆、AES 加密或自定义位运算）生成签名值，并写入名为 __cf_bm、ak_bmsc 或类似名称的 Cookie
后端如何校验这个 Cookie
后续请求（尤其是 POST 表单提交或关键 API）到达服务端时，后端会检查该 Cookie 是否存在、是否过期、签名是否可被还原验证。校验不是简单比对字符串，而是复现前端 JS 的计算逻辑：
- 提取请求中的动态 Cookie 值和对应时间戳
- 用相同密钥、相同算法、相同输入参数（如当前 URL、原始时间戳）重新计算一次哈希
- 比对结果是否一致；不一致则拒绝请求，返回 403 或跳转挑战页
为什么传统爬虫容易失效
requests、urllib 等 HTTP 库只发请求，不执行 JS，因此无法生成合法 Cookie。即使你手动复制了浏览器里的 Cookie，它通常含时效（如 5 分钟）、绑定 IP 或 User-Agent，过期或环境不匹配就会校验失败。
绕过这类防护必须具备 JS 执行能力：要么用 Puppeteer/Playwright 启动真实 Chromium 实例，让其自动执行页面 JS 并维护 Cookie；要么逆向前端逻辑，在 Python 中用 execjs 或手写等效算法模拟计算——但后者需处理混淆、WebAssembly、Canvas 指纹等进阶干扰。
表单防刷场景下的增强用法
针对询盘、注册、留言等高风险表单，可叠加两层 Cookie 防护：
- 第一层：页面加载时 JS 自动生成基础校验 Cookie（如 _token），提交前前端 JS 还需读取它参与表单字段加密
- 第二层：提交基础信息后，后端返回带签名的临时 token（如 submit_id=abc123&sig=xxx），跳转至确认页；最终提交时必须携带该 token，且服务端校验其签名+时效+来源 referer
这种“JS 生成 + 服务端签发 + 二次确认”结构，大幅增加自动化模拟成本，普通脚本难以串联完成整个链路。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
