中国裁判文书网请求参数每次不同是因为关键参数经前端动态AES加密后编码为q字段，密钥和iv由服务端动态下发，需模拟浏览器执行JS加密逻辑；同时存在Referer/User-Agent/TLS指纹等多重校验，须复用session并精确设置请求头；验证码与滑块验证难以绕过，需控频或接入打码平台；文书内容需二次解密解析，且结构复杂、持续更新反爬策略。
文书网的请求参数为什么每次都不一样
因为中国裁判文书网（wenshu.court.gov.cn）对 pageNum、sortFields、conditions 等关键参数做了前端动态加密，实际发包时提交的是 q 字段，其值是 AES 加密 + Base64 编码后的结果，密钥和 iv 每次由服务端下发（通过 /api/generateCode 或首页 JS 中的随机字符串生成逻辑推导）。
直接硬编码参数或复用旧 q 值会返回 {"code":"2","msg":"参数错误"} 或空数据。真实爬取必须模拟浏览器执行加密逻辑，不能靠抓包重放。
- 主流解法是用
execjs或PyExecJS执行官网 JS 中的encrypt函数（位于首页 HTML 的var encrypt = function(...)或静态资源/static/js/search.js） - 注意 JS 中的密钥生成依赖当前时间戳和随机数，需同步提取
token和ts（通常在/api/generateCode响应头或 JSON 中） - 部分新版页面改用 WebAssembly 模块做加密，此时
execjs失效，得用playwright或undetected-chromedriver启动真实浏览器上下文
防盗链（Referer / User-Agent）校验怎么绕过
文书网对 Referer 严格校验：请求必须来自 https://wenshu.court.gov.cn/website/wenshu/ 或具体子路径，且 User-Agent 需匹配主流浏览器（如 Chrome 120+），否则返回 403 Forbidden 或跳转到验证页。
单纯加 headers 不够——它还会检查 TCP 连接特征、TLS 指纹、HTTP/2 设置等。简单 requests 请求大概率被拦截。
立即学习“Python免费学习笔记（深入）”；
- 必须复用同一 session，并在首次访问首页后提取
Set-Cookie中的QINGCLOUD、SESSION等字段，后续所有请求携带完整 cookie -
Referer要精确到带查询参数的完整 URL，例如：https://wenshu.court.gov.cn/website/wenshu/181107ANFZ0BXSK4/index.html?pageId=xxx - 推荐用
requests.Session()+requests.adapters.HTTPAdapter(pool_connections=10, pool_maxsize=10)控制连接复用，避免被识别为扫描器
如何稳定获取有效验证码并完成人机校验
高频请求会触发图形验证码（/api/viewCode）或滑块验证（新版）。验证码不是纯图片，而是含动态干扰线 + 字体变形 + canvas 渲染的混合体，OCR 识别率极低；滑块则依赖鼠标轨迹模拟。
官方未开放验证码识别接口，也无公开 bypass 方式。强行暴力识别或跳过会导致 IP 封禁（封禁时长从 5 分钟到 24 小时不等）。
- 优先降低请求频率：单 IP 每分钟不超过 3–5 次，每次间隔 ≥ 12 秒，配合随机 jitter（±2s）
- 验证码请求前先
GET /api/generateCode获取token和uuid，再用该 token 请求/api/viewCode?uuid=xxx，否则返回空图 - 真要自动化识别，只能接入第三方打码平台（如超级鹰、云打码），但成本高、延迟大，且平台本身可能被文书网反制
法律文书数据的结构解析难点在哪
文书正文不是纯 HTML，而是服务端渲染的 iframe 内嵌 PDF 或富文本，实际接口返回的是加密的 content 字段（Base64 + 自定义解密），解密密钥藏在响应头 X-Response-Key 或 JS 变量中。
即使拿到原始 content，还需处理：HTML 实体转义、多余换行合并、法院名称标准化（“北京市朝阳区人民法院” vs “北京市朝阳法院”）、案号正则提取（(\d{4})[\u4e00-\u9fa5]+?(\d+)号）等。
- 不要用
BeautifulSoup直接解析返回的 JSON 中的html字段——那是模板占位符，真实内容需二次请求/website/wenshu/ShowWenshu接口 - 注意文书存在“隐藏内容”，如部分敏感信息被
<span class="mask">***</span>包裹，需主动替换或跳过 - 批量解析建议用
lxml替代bs4，速度更快且对 malformed HTML 更鲁棒
最麻烦的不是加密或反爬，而是文书网不定期更新前端逻辑——某天发现 encrypt 函数签名变了、q 多了一层 RSA 封装、或者滑块验证强制启用，都得重新逆向 JS。没有一劳永逸的方案，只有持续跟进和最小化请求扰动。
