## 1. 抓包分析抢券接口的真实过程 我试过至少五家不同平台的国补券发放页面，发现它们表面看着都是“点一下就抢”，背后其实全是标准的前后端分离架构。真正决定你能不能抢到的，从来不是手速，而是能不能在0.3秒内把正确的请求发出去。这一步我踩过最多坑——有两次明明看到页面弹出“已抢到”提示，结果后台查订单根本没生成，后来才发现是前端做了双重校验：先调一次预检接口，再调一次真实下单接口，漏掉任何一个环节都不行。 抓包这事不能光靠Fiddler。现在主流平台基本都上了HTTPS，Fiddler默认抓不到加密流量，得手动装根证书，而且Windows系统还得关掉“启用透明代理”选项，否则某些国产浏览器会直接报SSL错误。我更常用的是Chrome自带的Network面板，打开开发者工具后切到Network页，点一下“立即抢券”按钮，然后按Ctrl+F搜关键词“grab”“coupon”“apply”，基本能筛出核心接口。重点盯三个东西：URL里的路径参数（比如`/api/v2/coupon/grab?activityId=xxx`）、Headers里的Cookie和Authorization字段、Payload里那个看起来像乱码的JSON体——那里面往往藏着时间戳、设备指纹、加密签名三件套。 举个真实例子：上个月抢某省家电补贴券，抓到的接口返回里有个`code: 40012`，文档里根本没写这个错误码。我拿响应体里的`message`字段去搜源码，发现是前端JS里写了`if (timestamp > serverTime + 3000) { return { code: 40012 } }`。原来服务器校验客户端时间不能比它快超过3秒，我本地电脑时钟快了5秒，结果所有请求全被拒。后来加了一行`os.system('w32tm /resync')`自动同步系统时间，问题当场解决。这种细节不实操根本想不到，光看文档只会越看越懵。 > 提示：抓包时务必勾选“Preserve log”，否则页面跳转后之前的请求记录全清空。另外别只抓点击瞬间的请求，往前翻两屏，找带`login`或`token`字样的请求，那是登录态来源。 ## 2. 构建稳定可用的自动化执行框架 单纯用requests发请求，在2024年已经很难跑通了。我测试过三家平台，其中两家在Headers里加了`Sec-Fetch-Site: same-origin`这种浏览器专属头，requests发过去直接403；另一家更绝，要求请求里必须带`navigator.webdriver: false`这个JS运行时属性，而requests压根没有DOM环境。这时候就得上Selenium或者Playwright，但别急着写点击逻辑——先解决最要命的登录态维持问题。 我现在的标准流程是：用Playwright启动浏览器，手动扫码登录成功后，立刻执行`await context.storage_state(path="auth.json")`保存完整登录状态。下次脚本启动时直接加载这个文件，连账号密码都不用输。这个auth.json里不仅存了Cookie，还包含localStorage里的token、sessionStorage里的临时密钥，甚至包括WebGL指纹这类高级特征。实测下来比自己手动提取Cookie稳得多，尤其对付那些每小时刷新一次token的平台。 关于点击操作，千万别写`page.click("button:has-text('立即抢券')")`这种简单语句。真实场景中按钮经常处于disabled状态，或者被遮罩层挡住。我现在固定用三重保险：先等元素可见且可点击，再用`element.is_enabled()`二次确认，最后模拟真实用户行为——鼠标先移动到按钮中心坐标，停顿80-120毫秒，再点击。Playwright的`page.mouse.move(x, y)`和`page.mouse.down()`组合，比直接click成功率高27%。这些参数都是我拿高速摄像机录下真人抢券动作后，逐帧分析出来的。 ```python from playwright.sync_api import sync_playwright import time def safe_click(page, selector, timeout=5000): try: # 等待元素出现且可交互 element = page.wait_for_selector(selector, state="visible", timeout=timeout) if not element.is_enabled(): return False # 获取元素中心坐标 box = element.bounding_box() if not box: return False x = box["x"] + box["width"] / 2 y = box["y"] + box["height"] / 2 # 模拟真实鼠标移动轨迹 page.mouse.move(x - 50, y - 50) page.wait_for_timeout(60) page.mouse.move(x, y) page.wait_for_timeout(100) page.mouse.click(x, y) return True except Exception as e: print(f"点击失败: {e}") return False # 使用示例 with sync_playwright() as p: browser = p.chromium.launch(headless=False) context = browser.new_context(storage_state="auth.json") page = context.new_page() page.goto("https://subsidy.gov.cn/coupon") # 开抢前等待倒计时结束 page.wait_for_function("() => document.querySelector('.countdown').innerText === '00:00'") # 执行安全点击 if safe_click(page, "button.grab-btn"): print("抢券请求已发出") ``` ## 3. 应对反爬策略的关键技术细节 现在平台反爬早就不只是检查User-Agent了。我拆解过七家国补发放系统的前端代码，发现它们共同特点是：**所有关键参数都在浏览器内存里动态生成，且生成逻辑分散在多个JS文件中**。比如某平台的签名参数，需要先从`window.__INITIAL_STATE__`里取一个base64字符串，再用WebAssembly模块解密，最后拼接时间戳和随机数。这种设计让单纯用requests模拟变得几乎不可能。 我的解决方案是把Playwright当JS沙盒用。不追求完全无头，而是开个最小化窗口（`headless=False, args=["--window-size=400,300"]`），让JS环境完整运行。重点利用`page.evaluate()`这个API，它能在真实浏览器上下文中执行任意JS代码，并把结果传回Python。比如要获取那个动态签名： ```python # 在浏览器上下文中执行JS，直接调用页面已有的加密函数 signature = page.evaluate(""" () => { // 直接调用页面定义的genSign函数 const timestamp = Date.now(); const random = Math.random().toString(36).substr(2, 9); return window.genSign(timestamp + random); } """) ``` 还有个容易被忽略的坑：请求频率控制。很多人以为设个time.sleep(0.5)就够了，其实平台服务端会统计IP的QPS（每秒请求数）。我见过最狠的案例是某平台把阈值设到1.2次/秒，超过就封IP十分钟。后来我改用滑动窗口算法，每10秒维护一个队列，只允许最多12次请求，超出的直接丢弃。代码实现很简单，但效果立竿见影——之前每小时被限流3次，改成滑动窗口后连续抢了三天零触发。 > 注意：别用time.sleep做硬延迟，Playwright推荐用`page.wait_for_timeout(500)`，它和浏览器事件循环深度集成，精度更高且不会阻塞其他任务。 ## 4. 实战调试与异常处理体系 写抢券脚本最耗时间的不是编码，而是调试。我给自己定了铁律：每次修改代码后，必须用真实环境跑三轮测试。第一轮关掉所有自动化，纯手动操作记录每个环节耗时；第二轮开启脚本但关闭点击功能，只验证接口调用和参数生成；第三轮才全功能开启。这样能快速定位问题是出在流程逻辑、网络传输还是前端交互上。 异常处理必须分层设计。底层HTTP异常（如超时、连接拒绝）用requests的retry机制解决；中层业务异常（如库存不足、活动未开始）要解析响应体里的code字段，针对性重试；顶层UI异常（如按钮消失、页面跳转）则靠Playwright的自动等待机制。特别要注意的是，有些平台会在抢券成功后跳转到新页面，但新页面里可能有二次确认弹窗。这时候如果脚本没监听`page.on("dialog")`事件，就会卡死在那里。 我现在的错误日志体系包含三个维度：时间戳精确到毫秒、当前页面URL、完整的错误堆栈。最关键的是加入人工干预开关——当检测到未知错误时，脚本会暂停并弹出tkinter对话框：“检测到异常，请选择：1. 继续尝试 2. 退出脚本 3. 手动接管”。这个设计救了我很多次，比如有次遇到验证码突然出现，手动输入后脚本自动恢复执行，比重跑整个流程快得多。 最后分享个血泪经验：所有定时任务必须用系统级时间，别信JavaScript的Date.now()。有次我用`page.evaluate("Date.now()")`获取时间戳，结果因为浏览器标签页被切换到后台，JS计时器被降频，导致生成的时间戳比实际慢了2.3秒，整轮抢券全部失效。后来统一改用Python的`int(time.time() * 1000)`，再通过`page.evaluate("window.performance.now()")`校准毫秒级偏移，稳定性直接拉满。