简介这款自动抢券脚本源码包面向电商平台抢券需求尤其适用于某宝等活动的半自动化操作是编程爱好者学习浏览器自动化控制的实用示例。脚本借助JavaScript配合Selenium模拟刷新与点击重点解决了刷新时控制台代码保留、操作完毕后自动关闭页面等实际问题可有效提高抢券成功率。压缩包内共3个文件包含html入口页面、inscode配置及gitignore文件整体仅6KB结构简洁、便于直接部署调试。源码中以frameset加载目标页面通过ID与标签名精确定位抢券按钮并执行点击读者可从中掌握自动刷新间隔设置、DOM元素定位和页面生命周期管理的关键技巧也附带了运行异常的处理思路适合作为初学者的动手参考。目前已有451人学习下载。1. 为什么我决定写一个抢券脚本以及它的核心工作方式先交代个实际场景。618、双11、双12平台定时发券我手动点的时候永远慢半拍页面刚刷出来就提示“已抢光”。后来我盯着网络请求看了一次发现发券瞬间从用户点击到请求到达服务器耗时往往在300到800毫秒之间。这个延迟足够让几万人在你前面排队了。手动点击根本拼不过程序直接发HTTP请求的速度所以才有了这篇分享。自动抢券脚本本质上是把“人在屏幕前盯着按钮、时间到就点”这件事替换成“程序在后台按约定时间调用接口”。它解决了三件事一是绕过人类反应速度的上限二是解放双手不用一直盯着屏幕三是把抢券过程固定成可重复执行的流程。这篇博文适合想入门HTTP自动化、想给某个电商或平台写定时任务脚本的朋友。读完你能掌握一个可运行的抢券脚本样例知道怎么处理登录态、时间同步、重试策略也会明白为什么有些脚本会被平台拦下来。先说清楚抢券脚本的三种主流实现路径各有适用场景模拟点击UI自动化用PyAutoGUI、Selenium这类工具控制鼠标点击屏幕上的按钮。优点是通用性强只要页面长那样就能用缺点是慢而且受页面布局、弹窗、渲染延迟影响非常脆弱。接口直调HTTP请求直接对发券接口发出POST/GET请求。速度最快毫秒级也是最便于部署的。难点在于你要分析出接口地址、参数格式、登录凭证。无障碍服务移动端Android端通过无障碍服务监听界面节点自动触发点击。适合App内抢券但需要长时间后台运行耗电高且部分机型会被系统限制。我做的是接口直调版本因为它最能体现“自动化”的爽感也不依赖GUI环境。下面的源码就是基于这个思路写的。2. 可运行的抢券脚本源码与核心配置说明先给完整可运行的Python脚本需要的依赖只有requests一个库。代码里我把每个功能模块都用注释标出来了方便你按实际场景修改。 自动抢券脚本 - 独立运行版本 适用场景: 电商平台定时发放优惠券、商城积分兑换券等 依赖: pip install requests import requests import time import json import logging import os from datetime import datetime from threading import Thread # 配置区按实际情况修改 LOGIN_API https://example.com/api/login # 登录接口 COUPON_API https://example.com/api/grab_coupon # 抢券接口 USERNAME your_username PASSWORD your_password COUPON_ID 12345 # 目标券ID GRAB_TIME 2024-06-18 10:00:00 # 发券时间本地时区 THREAD_COUNT 1 # 并发线程数谨慎修改 LOG_FILE grab_coupon.log # 日志配置 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(LOG_FILE, encodingutf-8), logging.StreamHandler() ] ) logger logging.getLogger(coupon_bot) class CouponGrabber: def __init__(self): self.session requests.Session() self.session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://example.com/coupon-center, Origin: https://example.com }) self.token None self.grabbed False def login(self): 登录并保存会话凭证。多数平台的凭证有效期在30分钟到2小时之间。 payload { username: USERNAME, password: PASSWORD } try: resp self.session.post(LOGIN_API, jsonpayload, timeout5) resp.raise_for_status() data resp.json() self.token data.get(token) or data.get(access_token) if self.token: self.session.headers.update({Authorization: fBearer {self.token}}) logger.info(登录成功) return True else: logger.error(登录响应中未找到token: %s, data) return False except Exception as e: logger.error(登录请求异常: %s, e) return False def check_session(self): 检测当前会话是否有效。可以在抢券前调用一次避免带着死token去抢。 check_api https://example.com/api/user_info try: resp self.session.get(check_api, timeout3) if resp.status_code 200: return True return False except Exception: return False def grab_once(self): 单次抢券请求返回是否成功以及服务器返回的信息。 payload { coupon_id: COUPON_ID, source: script_v1, timestamp: int(time.time() * 1000) } try: resp self.session.post(COUPON_API, jsonpayload, timeout3) result resp.json() logger.info(抢券响应: %s, json.dumps(result, ensure_asciiFalse)) if result.get(code) 0 or result.get(success) is True: self.grabbed True return True, result return False, result except Exception as e: logger.error(抢券请求异常: %s, e) return False, {error: str(e)} def wait_until(self, target_str): 精确等待到目标时间提前100毫秒开始发送请求补偿网络耗时。 target datetime.strptime(target_str, %Y-%m-%d %H:%M:%S) while True: now datetime.now() if now target: return remaining (target - now).total_seconds() if remaining 0.1: return time.sleep(0.01) def run(self): 主流程登录 - 校准时间 - 循环抢券 - 结果反馈 if not self.login(): logger.error(登录失败脚本终止) return # 抢券前确认会话有效无效则重新登录 if not self.check_session(): logger.warning(会话失效尝试重新登录) if not self.login(): return logger.info(等待发券时间: %s, GRAB_TIME) self.wait_until(GRAB_TIME) max_attempts 20 for attempt in range(1, max_attempts 1): if self.grabbed: break logger.info(第%d次尝试, attempt) success, result self.grab_once() if success: logger.info(抢券成功! 第%d次尝试命中, attempt) break # 快速重试时间隔不要太大但也不能太密被判风控 time.sleep(0.2) if not self.grabbed: logger.error(达到最大尝试次数仍未抢到) def run_multi(): 多线程并发入口。默认关闭需要并发时取消注释。 grabber CouponGrabber() grabber.run() if __name__ __main__: logger.info(自动抢券脚本启动) # 单线程版本 run_multi() # 如果你确定接口支持并发且不会被封使用下面这种并发方式 # threads [] # for _ in range(THREAD_COUNT): # t Thread(targetrun_multi) # t.start() # threads.append(t) # for t in threads: # t.join()2.1 这段脚本里的几个关键设计意图统一用Session而不裸用requestsSession会自动维护Cookie对需要登录的接口尤其重要。每次请求都自己拼Cookie容易漏Session让框架帮你管。提前100毫秒发起请求这是我实测下来比较合适的补偿值。网络从客户端到服务器一般需要50到150毫秒提前100毫秒可以把“到达服务器的时间点”和“开抢时间点”对齐。这个值在不同网络环境下有差异建议先跑几次抓包看延迟再调整。请求参数里带timestamp字段很多平台的接口会对请求时间做校验时间戳太旧会被拒绝。带上毫秒级时间戳既是平台常见要求也方便排查问题。日志记录到文件和控制台抢券是短时间密集操作失败原因五花八门没有日志就没法复盘。文件日志和控制台双写是我的习惯出问题直接翻LOG_FILE。3. 抢券最容易翻车的五个细节实战踩坑记录直接给清单这五个问题我在测试过程中全都遇到过任何一个都能让脚本白跑。3.1 本地时间与服务器时间不一致这是最坑的一个。你按本地10:00:00发请求服务器按它自己的10:00:00判断两边只要差几百毫秒结果就是“活动未开始”或者“活动已结束”。处理办法启动脚本前先获取服务器时间。很多平台都有时间同步接口往往是一个返回server_time的轻量接口脚本启动时请求一次算出本地时间与服务器时间的偏移量在后面wait_until里加上这个偏移。# 获取服务器时间偏移量的示例 def get_server_offset(self): try: resp self.session.get(https://example.com/api/server_time, timeout3) server_time resp.json().get(timestamp) # 毫秒级 local_time int(time.time() * 1000) return server_time - local_time except Exception: return 0 # 在 wait_until 里使用 # target_ts datetime.strptime(target_str, %Y-%m-%d %H:%M:%S).timestamp() # adjusted_ts target_ts (self.server_offset / 1000)3.2 登录token过期登录凭证的过期时间因平台而异短的30分钟长的一周。抢券脚本经常是提前很长时间挂着等等到开抢时token已经失效了。解决办法在run()里抢券前先调一次check_session()失效就重新登录。我在脚本里已经写好了这个流程但如果你在改动时把它删了一定要补回去。3.3 接口带签名或加密参数很多平台会在请求参数里加一个sign字段通常是时间戳、用户ID、固定盐值做MD5/SHA256。这种接口没法直接改参数硬冲需要你在页面源码或者抓包数据里找到签名算法。常见做法是找JS里加密函数用Python复刻一遍。这部分工作量不小但没有捷径。3.4 重复提交被风控有些平台会限制同一账号短时间内的请求次数一旦触发风控轻则响应变慢重则封号。我的策略是单账号用单线程每次请求间隔控制在100到300毫秒之间不要狂点。多账号并发时要给不同账号加随机延迟避免所有账号在同一毫秒发出请求。3.5 没有做好响应解析抢券接口的返回格式五花八门有的是{code:0}表示成功有的是{success:true}有的是HTTP状态码200但body里写{status:fail}。脚本里我做了兼容判断result.get(code) 0 or result.get(success) is True。你拿到目标接口后一定先手动模拟几次请求确认成功和失败的判断条件再写死。4. 从热搜里发现的隐藏需求把抢券脚本当成稳定的小型自动化工具来设计我在搜相关资料的时候注意到一个热搜词“设备老化测试全自动执行脚本”。乍一看跟抢券没关系但背后的逻辑是相通的脚本要能长时间稳定运行、要在异常情况下自动恢复、要输出完整的运行日志。抢券脚本也一样。它不是在终端里敲一次就完事的玩具而是要挂着跑好几个小时的生产工具。按照这个标准有四个方面值得认真设计。4.1 异常捕获要“分层”不要全部吞掉我在脚本里用了try-except但捕获并不是越宽越好。我的原则是网络异常超时、连接重置——记录日志重试业务异常返回code表示失败——记录业务码和message重试数据格式异常返回的不是JSON——记录原始响应停止重试原因很简单网络异常重试有意义业务码失败重试也可能成功比如券还有剩余但如果你连响应内容都解析不出来说明接口变了再重试只会浪费资源。4.2 用可读性强的日志辅助问题定位日志的关键是“事后能还原现场”。我见过太多脚本只print一句“failed”完全没有上下文出了问题根本没法定。推荐格式是时间 - 级别 - 模块 - 消息并且把请求的URL、参数、响应body都打进去。开发阶段打得详细一点没关系正式跑的时候把级别调到INFO基本一眼能看出卡在哪一步。4.3 重试策略要“有上限、有退避”无上限重试是脚本的天敌。如果券已经领过了接口会一直返回“手气不足”之类的错误你还在那儿每0.2秒重试一次纯属浪费。我的做法是固定最大尝试次数例如20次每次间隔0.2秒。这样即使连续失败脚本也会在数秒内自行结束不会形成死循环。4.4 预留手动中断的开关抢券脚本大概率会在后台跑着如果你手动关闭终端可能造成Session非正常中断。建议在脚本前加一个try-except KeyboardInterrupt确保中断时能记录一条“手动停止”日志方便后续判断是人为停止还是意外退出。5. 把脚本部署到远程环境的完整流程本地电脑上跑脚本有个隐患待机、锁屏、断网都会中断任务。我实际使用中最稳的方案是部署到一台常驻的小型云服务器或者旧手机上让它7×24小时在线。5.1 在Linux服务器上跑定时任务的配置如果你用的是云服务器可以用crontab来定时启动脚本。# 每天早上9点50分执行一次抢券任务 50 9 * * * /usr/bin/python3 /opt/coupon_bot/main.py /var/log/coupon_bot_manual.log 21注意Python路径务必写绝对路径否则crontab环境里找不到解释器。另外脚本里所有日志路径、配置文件路径最好也用绝对路径因为crontab的当前目录和终端不一样。5.2 在Windows上跑开机自启Windows用户想开机自动运行可以用“任务计划程序”或者放一个.bat脚本到启动文件夹。echo off cd /d C:\coupon_bot python main.py.bat文件编码保存为ANSI不然中文注释会乱码。这是我在PowerShell里踩过的坑。5.3 注意服务器时间如果部署在云服务器上务必校准时区。除非你的目标平台明确使用UTC时间否则统一设置为北京时间或目标地区时区。sudo timedatectl set-timezone Asia/Shanghai时间不一致会导致脚本提前或延后发起请求很多时候不是脚本逻辑错了是时区设错了。6. 脚本上线前的完整测试步骤“可运行”不等于“稳定”。我每次改完脚本都会走一遍这个测试流程至少能排除80%的低级问题。6.1 测试环境与生产环境分离先用平台提供的测试接口如果有把登录、抢券流程跑通。没有测试环境的话找一个非高峰时段的券先试一发确认接口返回能被正确解析。6.2 模拟一次完整的“等待-抢券”过程把GRAB_TIME设成当前时间往后加1分钟跑一遍确认等待逻辑正常、抢券请求能发出、响应能正确记录。这一步最容易发现的是时间格式错误、等待循环条件写反、日志没输出这类低级问题。6.3 断网重连测试抢券过程中如果网络闪断requests会抛异常脚本应该能捕获并重试。我是手动断网10秒再恢复看脚本能不能继续跑不会因为一次网络抖动就退出。6.4 多账号并发测试如果你有多个账号先不要在同一秒启动所有脚本。我给不同账号设置一个微秒级的随机延迟比如账号A在整秒发送账号B在整秒30毫秒发送账号C在整秒70毫秒发送这样既不会集中在同一瞬间也不会明显看出来是脚本批量操作。7. 我踩过的一些坑以及最后补充的几句话写这个脚本前前后后改了三版。第一版用Selenium模拟点击虽然能跑但每次页面布局一变就要重写选择器第二版是纯requests直调速度快了很多但忽略了登录token过期问题开抢那一下连着失败几十次第三版才加上了会话检查、时间偏移、精确重试这些细节最终稳定下来。我个人最大的体会是自动抢券脚本的技术难度其实不高核心就三件事——登录态管理、时间对齐、接口参数正确。难点在于你永远不知道目标平台什么时候会调整接口所以脚本必须做成可配置、可观察、可快速修改的结构而不是一次性跑完就扔。最后分享一个小技巧抢券请求发出后不要马上认为成功就完事了建议加一个“结果主动拉取”的延后确认。也就是抢券接口返回成功之后过2到3秒再去查一次用户券包列表确认券真的到账了。因为有些平台的抢券接口是先返回“受理成功”后台异步入账极少情况下会入账失败。多查一次能避免“自认为抢到了”的误判。本文还有配套的精品资源点击获取