抢票这件事我前后折腾过好几个演出季。最早那会儿我也迷信手速决定一切定好闹钟、关掉所有后台、手指悬在屏幕上结果开票三秒页面就白了等刷新回来连候补按钮都灰了。后来我才慢慢想明白抢票本质上不是一场手速比赛而是一场信息处理速度和请求时机的较量——人眼识别验证码、手动点选场次、逐级翻页确认这套流程里每一步都在消耗几百毫秒而热门场次的门票往往在开票后一两秒内就被瓜分干净。于是我开始研究用脚本把重复且确定的操作交给程序去做把人的注意力留给真正需要判断的环节。这篇内容就是把我从零搭一套抢票辅助脚本的完整过程摊开来讲环境怎么配、请求怎么构造、页面元素怎么定位、失败怎么重试、以及最关键的——哪些地方看着能跑其实一上线就翻车。需要先把话说在前头脚本只是把机械操作自动化它不能凭空创造票源也不能绕过平台的正常购票规则。所有操作都应当在你自己的账号、正常的购票流程范围内进行遵守平台的服务条款理性看待结果。适合有一定编程基础、想理解自动化原理、或者单纯想搞明白为什么我手动抢不到的读者哪怕你最后不写一行代码这里面的请求时序、页面结构、状态机思路也能帮你看清整个购票链路的真实面貌。1. 先想清楚抢票脚本到底在自动化什么很多人一上来就问用什么语言写有没有现成的库这其实是把顺序搞反了。动手之前得先拆解一次完整的购票动作看清楚哪些环节是确定性重复、哪些是需要人判断的只有前者才值得交给脚本。1.1 一次购票动作的环节拆解把整个流程摊开大致是这么一条链路打开演出详情页 → 选择场次和票档 → 点击立即购买 → 选择观演人 → 提交订单 → 进入支付。这里面打开页面、选场次、选票档、点购买、选观演人、提交这几步只要目标明确参数就是固定的完全可以由程序按预设值自动执行而验证码识别、异常弹窗处理、库存突然释放的临场判断则属于需要人介入或者需要额外策略的部分。我习惯把这条链路画成一张状态表每个状态对应一个页面特征和一组可执行动作。这样做的好处是脚本不再是从头到尾跑一遍的线性代码而是一个能感知当前处于哪一步、该做什么的状态机。线性脚本最怕的就是某一步没加载出来后面全乱套状态机则可以反复轮询当前状态直到条件满足再推进。环节是否可自动化关键判断依据常见失败点打开详情页是页面标题/演出名称出现网络慢、页面白屏选场次票档是对应按钮可点击场次未开售、按钮置灰点击购买是按钮文案变为立即购买按钮被遮挡、需滚动选观演人是观演人列表加载完成列表异步加载延迟提交订单是提交按钮可用库存瞬时不足、风控拦截支付部分支付页出现通常建议人工完成这张表是我踩了无数坑之后总结出来的你会发现真正难的不是点击而是判断当前到底处于哪个状态。页面元素是异步加载的按钮文案会变弹窗会突然冒出来这些才是脚本稳定性的真正敌人。1.2 为什么手速不是瓶颈请求时序才是有个反直觉的结论在同样的网络条件下一个训练有素的人手动点击从看到按钮到点下去大约需要 200 到 400 毫秒而脚本从检测到按钮可用、到发出点击事件可以压缩到几十毫秒。听起来差距不大但热门场次的票是在开票瞬间的几百毫秒窗口里被抢完的这个量级的差距足以决定成败。更关键的是请求时序。手动操作时人是看到页面变了才反应而脚本可以做到提前把请求准备好一旦条件满足立刻发出。举个具体例子开票时间如果是 20:00:00手动用户往往在 19:59:59 就开始狂点结果要么点到未开售的提示要么点早了触发频率限制而脚本可以精确到毫秒级地在 20:00:00.050 左右发出第一个有效请求既不会太早被判为异常也不会太晚错过窗口。提示这里的精确时序指的是在你本地时钟与服务器时间大致对齐的前提下合理安排请求节奏。盲目高频请求不仅抢不到票还容易触发平台的风控机制导致账号被临时限制得不偿失。所以脚本的核心价值不在于点得快而在于把等待、检测、重试这些枯燥环节做得又稳又准。理解了这一点你就不会执着于哪个库点击最快而是会把精力放在状态检测的准确性和重试逻辑的健壮性上。1.3 技术选型的取舍逻辑选型这块我试过好几套方案最后落在一个比较务实的组合上。纯浏览器自动化比如用浏览器驱动去模拟点击上手快、直观但资源占用高、速度偏慢纯接口请求速度快但需要逆向分析请求参数维护成本高而且一旦平台调整参数签名就全废。我的建议是分阶段先用浏览器自动化把整个流程跑通、验证状态判断逻辑等逻辑稳定了再考虑把其中确定性强、参数固定的环节替换成更轻量的请求方式。具体到工具浏览器自动化这块主流的选择是 Selenium 和 Playwright。我最后偏向 Playwright原因很实际它的自动等待机制省去了大量手写 sleep 的麻烦元素定位失败时会自动重试到超时而且对现代前端框架渲染的页面支持更好。Selenium 生态更成熟、资料更多但需要自己处理各种显式等待新手容易写出满屏time.sleep的代码。方案上手难度执行速度维护成本适用阶段浏览器自动化Playwright中中低流程验证、逻辑调试浏览器自动化Selenium中中偏慢中兼容老项目接口请求高快高逻辑稳定后的提速混合方案高快中成熟期选型没有绝对的对错关键是匹配你当前所处的阶段。新手直接上接口请求往往卡在参数分析上就放弃了老手用纯浏览器自动化又会嫌它慢。先跑通再优化这个顺序不能乱。2. 环境搭建把地基打牢再谈速度环境这块是最容易被轻视、又最容易在关键时刻掉链子的部分。我见过太多人代码写得挺漂亮结果因为浏览器版本和驱动不匹配、或者依赖装错了版本开票前十分钟还在那排查报错。这一节把环境配置的每个细节都讲透照着做能避开大部分低级坑。2.1 运行环境与依赖的版本对齐先说语言环境。Python 是这类脚本最常用的选择生态全、库多、调试方便。我建议用Python 3.9 以上的版本太老的版本在异步处理和类型标注上会有各种别扭。装依赖的时候强烈建议用虚拟环境隔离别一股脑装到全局否则不同项目之间的库版本冲突能让你怀疑人生。# 创建并激活虚拟环境以常见命令为例 python -m venv ticket_env # Windows ticket_env\Scripts\activate # macOS / Linux source ticket_env/bin/activate # 安装核心依赖 pip install playwright playwright install chromium这里有个细节值得说playwright install chromium这一步会下载一个配套的浏览器内核这个内核版本是和你安装的 Playwright 库版本绑定的。很多人图省事直接用系统里已有的浏览器结果版本对不上各种诡异报错。老老实实用它自带的内核省心。依赖版本这块我习惯在项目里放一个requirements.txt把版本钉死比如playwright1.40.0这种。为什么因为自动化库的 API 在不同大版本之间偶尔会有破坏性变更你今天跑通的代码明天pip install拉了个新版本可能就报错了。钉死版本等于给项目上了个保险。2.2 浏览器驱动的隐性坑如果你用的是 Selenium那驱动管理是个绕不开的坎。浏览器会自动更新但驱动不会某天早上你打开电脑发现浏览器升了个大版本脚本直接报session not created。解决办法有两个一是用webdriver-manager这类工具自动匹配驱动版本二是干脆锁定浏览器不自动更新。Playwright 在这方面省心很多因为它用的是自己下载的内核不受系统浏览器更新影响。但也不是完全没坑——如果你在 CI 环境或者容器里跑可能会缺一些系统依赖库导致浏览器起不来。遇到这种情况Playwright 提供了playwright install-deps命令来补装系统依赖这个在 Linux 环境下特别有用。注意无论用哪种方案都建议在正式使用前做一次冷启动测试——把电脑重启然后直接运行脚本看能不能一次跑通。很多环境问题是热环境下发现不了的比如某个后台服务没起来、某个路径没配好冷启动才能暴露。2.3 一个可复用的启动配置模板我把浏览器的启动参数整理成了一个模板每次新项目直接抄。核心思路是既要让页面正常渲染又要尽量减少被识别为自动化的特征同时保证稳定性。from playwright.sync_api import sync_playwright def create_browser(): pw sync_playwright().start() browser pw.chromium.launch( headlessFalse, # 调试阶段建议有头方便观察 args[ --disable-blink-featuresAutomationControlled, --no-sandbox, --disable-dev-shm-usage, ] ) context browser.new_context( viewport{width: 1280, height: 800}, user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 ) page context.new_page() return pw, browser, context, page几个参数解释一下headlessFalse在调试阶段一定要开你得亲眼看着脚本在页面上做了什么出问题才好定位--disable-blink-featuresAutomationControlled是为了减少一些明显的自动化特征--disable-dev-shm-usage在容器环境里能避免共享内存不足导致的崩溃。user_agent设一个常见的桌面浏览器标识让页面按正常桌面版渲染避免被引导到精简版页面导致元素定位失败。这套配置不是万能的但它是一个稳定的起点。等你把流程跑通了再根据实际情况微调比一上来就追求完美隐身要务实得多。3. 页面元素定位脚本的眼睛怎么练元素定位是脚本稳定性的命门。定位写得好页面小改版也能扛住定位写得烂平台换个样式类名你就得重写。这一节讲我怎么从能定位到进化到定位得稳。3.1 定位策略的优先级排序定位元素有好几种方式按 ID、按 CSS 选择器、按 XPath、按文本内容。我的优先级排序是这样的稳定的语义属性 文本内容 结构化的 CSS 选择器 绝对 XPath。为什么把绝对 XPath 放最后因为绝对 XPath 依赖页面的完整层级结构比如/html/body/div[3]/div[2]/button平台只要在中间插一个 div整条路径就废了。而文本内容定位比如找到文案为立即购买的按钮虽然也可能因为文案调整而失效但相对来说更贴近用户的真实意图改版时也更容易发现和修复。实际写的时候我会优先找那些带有业务语义的属性比如># 推荐等待元素出现最多等 10 秒 page.wait_for_selector(text立即购买, timeout10000) # 不推荐死等固定时间 import time time.sleep(5)还有一种情况是元素出现了但不可点击比如按钮还在置灰状态、或者被一个 loading 遮罩盖住。这时候光等出现不够还得等可点击。Playwright 的click方法自带可点击性检查会等到元素可见、稳定、能接收事件才点这个特性非常省心。3.3 用文本和角色定位的实战写法我实际项目里用得最多的定位方式是按角色加文本。比如一个按钮用page.get_by_role(button, name立即购买)这种写法既表达了这是一个按钮的语义又用文案做了区分可读性和稳定性都不错。# 按角色和名称定位按钮 page.get_by_role(button, name立即购买).click() # 按文本定位场次选项 page.get_by_text(2024-12-31 周六 19:30).click() # 定位观演人复选框假设有 aria-label page.get_by_role(checkbox, name张三).check()这种写法的好处是代码读起来就像在描述用户的操作点击名为立即购买的按钮选择这个场次勾选这个观演人。将来页面改版你对照着报错信息一眼就能看出是哪一步的定位失效了维护成本低很多。提示定位写完之后一定要在真实页面上反复测试包括页面刚加载、加载到一半、完全加载这几种状态。有些元素在加载过程中会短暂出现又消失比如骨架屏如果你的定位恰好命中了这个瞬时元素就会点到一个不存在的东西上。4. 核心流程编排把零散动作串成可靠链路环境有了、定位会写了接下来是把这些零件组装成一台能跑的机器。这一节讲流程编排的思路重点在状态判断和重试设计这两块决定了脚本是玩具还是工具。4.1 用状态机替代线性脚本前面提过状态机的思路这里展开讲怎么落地。核心是把整个购票流程拆成若干个状态每个状态有明确的进入条件和退出动作。脚本主循环不断检测当前处于哪个状态然后执行对应动作直到到达终态下单成功或明确失败。def detect_state(page): if page.query_selector(text立即购买): return READY_TO_BUY if page.query_selector(text选择观演人): return SELECT_ATTENDEE if page.query_selector(text提交订单): return CONFIRM_ORDER if page.query_selector(text支付): return PAY return UNKNOWN def run_flow(page): for _ in range(200): # 最多轮询 200 次 state detect_state(page) if state READY_TO_BUY: page.get_by_role(button, name立即购买).click() elif state SELECT_ATTENDEE: page.get_by_role(checkbox, name张三).check() page.get_by_role(button, name确定).click() elif state CONFIRM_ORDER: page.get_by_role(button, name提交订单).click() elif state PAY: print(已进入支付页请人工完成支付) break page.wait_for_timeout(200) # 轮询间隔这段代码的关键在于detect_state函数——它像一双眼睛每次循环都重新看一眼页面现在长什么样。这样即使某一步加载慢了、或者弹了个意外提示脚本也不会像线性代码那样直接崩掉而是会继续轮询等页面回到预期状态再推进。4.2 重试机制的设计要点重试不是简单地失败了再来一次那样很容易陷入死循环或者触发风控。我的重试设计遵循三个原则有限次数、递增间隔、区分错误类型。有限次数好理解不能无限重试。递增间隔是指每次重试的等待时间逐渐拉长比如第一次等 200 毫秒、第二次 400 毫秒、第三次 800 毫秒这样既能快速响应瞬时故障又不会在持续故障时疯狂刷请求。区分错误类型则是最容易被忽略的——元素没找到和网络超时是两种完全不同的错误前者可能需要刷新页面后者只需要等一等再试。def retry_action(action, max_retries3, base_delay0.2): for attempt in range(max_retries): try: return action() except Exception as e: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) # 指数退避 print(f第 {attempt1} 次失败{e}{delay:.1f}s 后重试) time.sleep(delay)指数退避这个模式在自动化里非常通用它能在保证响应速度的同时避免对目标服务造成不必要的压力。这也是一个负责任的脚本应该具备的基本素养。4.3 库存释放的临场应对热门场次经常出现开票即售罄但过几分钟又零星放出几张的情况这叫库存释放。手动用户很难盯住这种随机释放而脚本可以持续轮询购买按钮是否重新可用。我的做法是在主流程之外挂一个轻量轮询当检测到已售罄状态时不退出而是每隔几秒刷新一次页面检查按钮是否恢复可点击。一旦恢复立刻回到主流程。这个轮询的频率要克制几秒一次足够太频繁既没必要又容易触发限制。注意库存释放的时机完全不可预测脚本能做的只是不错过而不是保证抢到。心态上要摆正把它当成一个提高概率的辅助工具而不是必胜法宝。5. 那些上线才暴露的坑我的踩坑排查实录前面讲的都是应该怎么做这一节讲实际会怎么翻车。这些坑我在文档里几乎没见过全是自己一行行调试、一次次失败攒出来的经验。5.1 元素明明在就是点不到这是最经典的坑。报错信息说元素不可点击但你打开开发者工具一看元素明明好好地待在那儿。原因通常有三种一是元素被一个透明的遮罩层盖住了比如 loading 动画还没消失二是元素在可视区域之外需要滚动才能点到三是元素虽然可见但尺寸为零或者被 CSS 设成了pointer-events: none。排查的时候我一般先截图看当前页面长什么样再检查元素的位置和尺寸。Playwright 的click默认会尝试滚动到元素位置但如果遮罩层存在它还是会失败。这时候可以加一个等待遮罩消失的前置判断或者用forceTrue强制点击慎用可能点到错误的东西。5.2 页面跳转导致的上下文丢失购票流程里经常有新窗口或者 iframe 弹出比如选座页面、支付页面。如果你的脚本还盯着原来的页面对象操作就会报元素找不到。解决办法是在每次可能发生跳转的动作之后重新获取当前的页面或 frame 上下文。# 点击后可能打开新窗口 with page.context.expect_page() as new_page_info: page.get_by_role(button, name立即购买).click() new_page new_page_info.value new_page.wait_for_load_state()这种预期某个事件发生的写法比点完之后sleep再去找窗口要可靠得多因为它是在事件真正发生时立刻捕获不会因为等待时间不够而错过。5.3 验证码与风控的边界这里必须把话说清楚验证码是平台用来区分人和程序的安全机制脚本不应该、也不建议去破解它。我遇到验证码时的处理方式是——暂停自动流程提示人工介入由我自己完成验证后再继续。这既是遵守规则也是保护账号安全的务实做法。至于风控表现为请求被拒、页面返回异常、账号被临时限制等。应对思路不是对抗而是降低异常特征控制请求频率、模拟正常的操作间隔、避免在非开票时间做无意义的轮询。一个行为模式接近正常用户的脚本本身就不容易触发风控。异常现象可能原因应对思路请求被拒频率过高降低轮询频率加随机间隔页面返回异常触发风控暂停操作人工检查账号状态出现验证码行为异常暂停人工完成验证账号被限制多次异常停止操作等待限制解除5.4 时钟不同步带来的时序偏差这个坑很隐蔽。你以为 20:00:00 开票脚本也在 20:00:00 发请求结果平台显示未开售或者晚了半秒票就没了。问题出在本地时钟和服务器时钟存在偏差。解决办法是提前用网络时间协议校准本地时间或者在脚本里加一个可配置的偏移量根据实测结果微调。我一般会在开票前做一次对时测试在非开票时间观察页面上的倒计时和本地时间的差异估算出偏差量然后在脚本里补偿。这个细节看着小但在毫秒必争的场景里可能就是成败之分。6. 让脚本更稳的几个工程习惯写到这儿流程和坑都讲得差不多了。最后分享几个让脚本从能跑进化到好维护的工程习惯这些是我做了好几个项目之后才慢慢养成的。6.1 日志要记到能复盘的程度脚本跑挂了最怕的就是不知道为什么挂的。我的做法是每个关键动作都打日志什么时候检测到什么状态、执行了什么动作、耗时多少、结果如何。日志不用花哨但一定要包含时间戳、状态、动作、结果这四个要素。出问题的时候翻日志就能还原整个执行过程比盯着屏幕瞎猜高效得多。import logging logging.basicConfig( levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s ) logging.info(检测到状态 READY_TO_BUY准备点击购买)6.2 配置和代码分离场次、票档、观演人这些信息不要硬编码在代码里。把它们抽到一个配置文件比如 YAML 或 JSON里改需求的时候只改配置不动代码。这样做还有个好处同一套代码可以复用于不同的演出只要换配置就行。# config.yaml target: session: 2024-12-31 周六 19:30 price_tier: 看台 680 attendees: - 张三 - 李四 timing: start_offset_ms: 506.3 失败要能优雅退出脚本最忌讳的是卡死——既不成功也不报错就那么僵在那儿。所以每个等待都要设超时每个循环都要设上限任何异常都要有兜底处理。宁可明确地失败退出也不要无声无息地挂着那样你连问题出在哪都不知道。我在主流程外面套了一层总的超时控制超过预定时间还没到终态就主动退出并打印当前状态和截图。截图这个习惯特别有用很多时候看一眼截图就知道卡在哪一步了。6.4 尊重规则理性使用最后这点最重要。脚本是工具工具的价值在于帮人省去重复劳动而不是用来破坏公平或者钻空子。控制请求频率、遵守平台的购票规则、遇到验证码人工处理、不恶意占用资源——这些不是技术限制而是使用者的基本素养。一个负责任的自动化脚本应该让整个购票环境更有序而不是更混乱。我在实际使用中的体会是脚本真正帮我省下的是那些反复刷新、反复确认的精力让我能把注意力放在这场演出到底值不值得看这个价位合不合适这些真正需要判断的事情上。技术是手段看演出才是目的别本末倒置了。
抢票这件事我前后折腾过好几个演出季。最早那会儿我也迷信手速决定一切定好闹钟、关掉所有后台、手指悬在屏幕上结果开票三秒页面就白了等刷新回来连候补按钮都灰了。后来我才慢慢想明白抢票本质上不是一场手速比赛而是一场信息处理速度和请求时机的较量——人眼识别验证码、手动点选场次、逐级翻页确认这套流程里每一步都在消耗几百毫秒而热门场次的门票往往在开票后一两秒内就被瓜分干净。于是我开始研究用脚本把重复且确定的操作交给程序去做把人的注意力留给真正需要判断的环节。这篇内容就是把我从零搭一套抢票辅助脚本的完整过程摊开来讲环境怎么配、请求怎么构造、页面元素怎么定位、失败怎么重试、以及最关键的——哪些地方看着能跑其实一上线就翻车。需要先把话说在前头脚本只是把机械操作自动化它不能凭空创造票源也不能绕过平台的正常购票规则。所有操作都应当在你自己的账号、正常的购票流程范围内进行遵守平台的服务条款理性看待结果。适合有一定编程基础、想理解自动化原理、或者单纯想搞明白为什么我手动抢不到的读者哪怕你最后不写一行代码这里面的请求时序、页面结构、状态机思路也能帮你看清整个购票链路的真实面貌。1. 先想清楚抢票脚本到底在自动化什么很多人一上来就问用什么语言写有没有现成的库这其实是把顺序搞反了。动手之前得先拆解一次完整的购票动作看清楚哪些环节是确定性重复、哪些是需要人判断的只有前者才值得交给脚本。1.1 一次购票动作的环节拆解把整个流程摊开大致是这么一条链路打开演出详情页 → 选择场次和票档 → 点击立即购买 → 选择观演人 → 提交订单 → 进入支付。这里面打开页面、选场次、选票档、点购买、选观演人、提交这几步只要目标明确参数就是固定的完全可以由程序按预设值自动执行而验证码识别、异常弹窗处理、库存突然释放的临场判断则属于需要人介入或者需要额外策略的部分。我习惯把这条链路画成一张状态表每个状态对应一个页面特征和一组可执行动作。这样做的好处是脚本不再是从头到尾跑一遍的线性代码而是一个能感知当前处于哪一步、该做什么的状态机。线性脚本最怕的就是某一步没加载出来后面全乱套状态机则可以反复轮询当前状态直到条件满足再推进。环节是否可自动化关键判断依据常见失败点打开详情页是页面标题/演出名称出现网络慢、页面白屏选场次票档是对应按钮可点击场次未开售、按钮置灰点击购买是按钮文案变为立即购买按钮被遮挡、需滚动选观演人是观演人列表加载完成列表异步加载延迟提交订单是提交按钮可用库存瞬时不足、风控拦截支付部分支付页出现通常建议人工完成这张表是我踩了无数坑之后总结出来的你会发现真正难的不是点击而是判断当前到底处于哪个状态。页面元素是异步加载的按钮文案会变弹窗会突然冒出来这些才是脚本稳定性的真正敌人。1.2 为什么手速不是瓶颈请求时序才是有个反直觉的结论在同样的网络条件下一个训练有素的人手动点击从看到按钮到点下去大约需要 200 到 400 毫秒而脚本从检测到按钮可用、到发出点击事件可以压缩到几十毫秒。听起来差距不大但热门场次的票是在开票瞬间的几百毫秒窗口里被抢完的这个量级的差距足以决定成败。更关键的是请求时序。手动操作时人是看到页面变了才反应而脚本可以做到提前把请求准备好一旦条件满足立刻发出。举个具体例子开票时间如果是 20:00:00手动用户往往在 19:59:59 就开始狂点结果要么点到未开售的提示要么点早了触发频率限制而脚本可以精确到毫秒级地在 20:00:00.050 左右发出第一个有效请求既不会太早被判为异常也不会太晚错过窗口。提示这里的精确时序指的是在你本地时钟与服务器时间大致对齐的前提下合理安排请求节奏。盲目高频请求不仅抢不到票还容易触发平台的风控机制导致账号被临时限制得不偿失。所以脚本的核心价值不在于点得快而在于把等待、检测、重试这些枯燥环节做得又稳又准。理解了这一点你就不会执着于哪个库点击最快而是会把精力放在状态检测的准确性和重试逻辑的健壮性上。1.3 技术选型的取舍逻辑选型这块我试过好几套方案最后落在一个比较务实的组合上。纯浏览器自动化比如用浏览器驱动去模拟点击上手快、直观但资源占用高、速度偏慢纯接口请求速度快但需要逆向分析请求参数维护成本高而且一旦平台调整参数签名就全废。我的建议是分阶段先用浏览器自动化把整个流程跑通、验证状态判断逻辑等逻辑稳定了再考虑把其中确定性强、参数固定的环节替换成更轻量的请求方式。具体到工具浏览器自动化这块主流的选择是 Selenium 和 Playwright。我最后偏向 Playwright原因很实际它的自动等待机制省去了大量手写 sleep 的麻烦元素定位失败时会自动重试到超时而且对现代前端框架渲染的页面支持更好。Selenium 生态更成熟、资料更多但需要自己处理各种显式等待新手容易写出满屏time.sleep的代码。方案上手难度执行速度维护成本适用阶段浏览器自动化Playwright中中低流程验证、逻辑调试浏览器自动化Selenium中中偏慢中兼容老项目接口请求高快高逻辑稳定后的提速混合方案高快中成熟期选型没有绝对的对错关键是匹配你当前所处的阶段。新手直接上接口请求往往卡在参数分析上就放弃了老手用纯浏览器自动化又会嫌它慢。先跑通再优化这个顺序不能乱。2. 环境搭建把地基打牢再谈速度环境这块是最容易被轻视、又最容易在关键时刻掉链子的部分。我见过太多人代码写得挺漂亮结果因为浏览器版本和驱动不匹配、或者依赖装错了版本开票前十分钟还在那排查报错。这一节把环境配置的每个细节都讲透照着做能避开大部分低级坑。2.1 运行环境与依赖的版本对齐先说语言环境。Python 是这类脚本最常用的选择生态全、库多、调试方便。我建议用Python 3.9 以上的版本太老的版本在异步处理和类型标注上会有各种别扭。装依赖的时候强烈建议用虚拟环境隔离别一股脑装到全局否则不同项目之间的库版本冲突能让你怀疑人生。# 创建并激活虚拟环境以常见命令为例 python -m venv ticket_env # Windows ticket_env\Scripts\activate # macOS / Linux source ticket_env/bin/activate # 安装核心依赖 pip install playwright playwright install chromium这里有个细节值得说playwright install chromium这一步会下载一个配套的浏览器内核这个内核版本是和你安装的 Playwright 库版本绑定的。很多人图省事直接用系统里已有的浏览器结果版本对不上各种诡异报错。老老实实用它自带的内核省心。依赖版本这块我习惯在项目里放一个requirements.txt把版本钉死比如playwright1.40.0这种。为什么因为自动化库的 API 在不同大版本之间偶尔会有破坏性变更你今天跑通的代码明天pip install拉了个新版本可能就报错了。钉死版本等于给项目上了个保险。2.2 浏览器驱动的隐性坑如果你用的是 Selenium那驱动管理是个绕不开的坎。浏览器会自动更新但驱动不会某天早上你打开电脑发现浏览器升了个大版本脚本直接报session not created。解决办法有两个一是用webdriver-manager这类工具自动匹配驱动版本二是干脆锁定浏览器不自动更新。Playwright 在这方面省心很多因为它用的是自己下载的内核不受系统浏览器更新影响。但也不是完全没坑——如果你在 CI 环境或者容器里跑可能会缺一些系统依赖库导致浏览器起不来。遇到这种情况Playwright 提供了playwright install-deps命令来补装系统依赖这个在 Linux 环境下特别有用。注意无论用哪种方案都建议在正式使用前做一次冷启动测试——把电脑重启然后直接运行脚本看能不能一次跑通。很多环境问题是热环境下发现不了的比如某个后台服务没起来、某个路径没配好冷启动才能暴露。2.3 一个可复用的启动配置模板我把浏览器的启动参数整理成了一个模板每次新项目直接抄。核心思路是既要让页面正常渲染又要尽量减少被识别为自动化的特征同时保证稳定性。from playwright.sync_api import sync_playwright def create_browser(): pw sync_playwright().start() browser pw.chromium.launch( headlessFalse, # 调试阶段建议有头方便观察 args[ --disable-blink-featuresAutomationControlled, --no-sandbox, --disable-dev-shm-usage, ] ) context browser.new_context( viewport{width: 1280, height: 800}, user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 ) page context.new_page() return pw, browser, context, page几个参数解释一下headlessFalse在调试阶段一定要开你得亲眼看着脚本在页面上做了什么出问题才好定位--disable-blink-featuresAutomationControlled是为了减少一些明显的自动化特征--disable-dev-shm-usage在容器环境里能避免共享内存不足导致的崩溃。user_agent设一个常见的桌面浏览器标识让页面按正常桌面版渲染避免被引导到精简版页面导致元素定位失败。这套配置不是万能的但它是一个稳定的起点。等你把流程跑通了再根据实际情况微调比一上来就追求完美隐身要务实得多。3. 页面元素定位脚本的眼睛怎么练元素定位是脚本稳定性的命门。定位写得好页面小改版也能扛住定位写得烂平台换个样式类名你就得重写。这一节讲我怎么从能定位到进化到定位得稳。3.1 定位策略的优先级排序定位元素有好几种方式按 ID、按 CSS 选择器、按 XPath、按文本内容。我的优先级排序是这样的稳定的语义属性 文本内容 结构化的 CSS 选择器 绝对 XPath。为什么把绝对 XPath 放最后因为绝对 XPath 依赖页面的完整层级结构比如/html/body/div[3]/div[2]/button平台只要在中间插一个 div整条路径就废了。而文本内容定位比如找到文案为立即购买的按钮虽然也可能因为文案调整而失效但相对来说更贴近用户的真实意图改版时也更容易发现和修复。实际写的时候我会优先找那些带有业务语义的属性比如># 推荐等待元素出现最多等 10 秒 page.wait_for_selector(text立即购买, timeout10000) # 不推荐死等固定时间 import time time.sleep(5)还有一种情况是元素出现了但不可点击比如按钮还在置灰状态、或者被一个 loading 遮罩盖住。这时候光等出现不够还得等可点击。Playwright 的click方法自带可点击性检查会等到元素可见、稳定、能接收事件才点这个特性非常省心。3.3 用文本和角色定位的实战写法我实际项目里用得最多的定位方式是按角色加文本。比如一个按钮用page.get_by_role(button, name立即购买)这种写法既表达了这是一个按钮的语义又用文案做了区分可读性和稳定性都不错。# 按角色和名称定位按钮 page.get_by_role(button, name立即购买).click() # 按文本定位场次选项 page.get_by_text(2024-12-31 周六 19:30).click() # 定位观演人复选框假设有 aria-label page.get_by_role(checkbox, name张三).check()这种写法的好处是代码读起来就像在描述用户的操作点击名为立即购买的按钮选择这个场次勾选这个观演人。将来页面改版你对照着报错信息一眼就能看出是哪一步的定位失效了维护成本低很多。提示定位写完之后一定要在真实页面上反复测试包括页面刚加载、加载到一半、完全加载这几种状态。有些元素在加载过程中会短暂出现又消失比如骨架屏如果你的定位恰好命中了这个瞬时元素就会点到一个不存在的东西上。4. 核心流程编排把零散动作串成可靠链路环境有了、定位会写了接下来是把这些零件组装成一台能跑的机器。这一节讲流程编排的思路重点在状态判断和重试设计这两块决定了脚本是玩具还是工具。4.1 用状态机替代线性脚本前面提过状态机的思路这里展开讲怎么落地。核心是把整个购票流程拆成若干个状态每个状态有明确的进入条件和退出动作。脚本主循环不断检测当前处于哪个状态然后执行对应动作直到到达终态下单成功或明确失败。def detect_state(page): if page.query_selector(text立即购买): return READY_TO_BUY if page.query_selector(text选择观演人): return SELECT_ATTENDEE if page.query_selector(text提交订单): return CONFIRM_ORDER if page.query_selector(text支付): return PAY return UNKNOWN def run_flow(page): for _ in range(200): # 最多轮询 200 次 state detect_state(page) if state READY_TO_BUY: page.get_by_role(button, name立即购买).click() elif state SELECT_ATTENDEE: page.get_by_role(checkbox, name张三).check() page.get_by_role(button, name确定).click() elif state CONFIRM_ORDER: page.get_by_role(button, name提交订单).click() elif state PAY: print(已进入支付页请人工完成支付) break page.wait_for_timeout(200) # 轮询间隔这段代码的关键在于detect_state函数——它像一双眼睛每次循环都重新看一眼页面现在长什么样。这样即使某一步加载慢了、或者弹了个意外提示脚本也不会像线性代码那样直接崩掉而是会继续轮询等页面回到预期状态再推进。4.2 重试机制的设计要点重试不是简单地失败了再来一次那样很容易陷入死循环或者触发风控。我的重试设计遵循三个原则有限次数、递增间隔、区分错误类型。有限次数好理解不能无限重试。递增间隔是指每次重试的等待时间逐渐拉长比如第一次等 200 毫秒、第二次 400 毫秒、第三次 800 毫秒这样既能快速响应瞬时故障又不会在持续故障时疯狂刷请求。区分错误类型则是最容易被忽略的——元素没找到和网络超时是两种完全不同的错误前者可能需要刷新页面后者只需要等一等再试。def retry_action(action, max_retries3, base_delay0.2): for attempt in range(max_retries): try: return action() except Exception as e: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) # 指数退避 print(f第 {attempt1} 次失败{e}{delay:.1f}s 后重试) time.sleep(delay)指数退避这个模式在自动化里非常通用它能在保证响应速度的同时避免对目标服务造成不必要的压力。这也是一个负责任的脚本应该具备的基本素养。4.3 库存释放的临场应对热门场次经常出现开票即售罄但过几分钟又零星放出几张的情况这叫库存释放。手动用户很难盯住这种随机释放而脚本可以持续轮询购买按钮是否重新可用。我的做法是在主流程之外挂一个轻量轮询当检测到已售罄状态时不退出而是每隔几秒刷新一次页面检查按钮是否恢复可点击。一旦恢复立刻回到主流程。这个轮询的频率要克制几秒一次足够太频繁既没必要又容易触发限制。注意库存释放的时机完全不可预测脚本能做的只是不错过而不是保证抢到。心态上要摆正把它当成一个提高概率的辅助工具而不是必胜法宝。5. 那些上线才暴露的坑我的踩坑排查实录前面讲的都是应该怎么做这一节讲实际会怎么翻车。这些坑我在文档里几乎没见过全是自己一行行调试、一次次失败攒出来的经验。5.1 元素明明在就是点不到这是最经典的坑。报错信息说元素不可点击但你打开开发者工具一看元素明明好好地待在那儿。原因通常有三种一是元素被一个透明的遮罩层盖住了比如 loading 动画还没消失二是元素在可视区域之外需要滚动才能点到三是元素虽然可见但尺寸为零或者被 CSS 设成了pointer-events: none。排查的时候我一般先截图看当前页面长什么样再检查元素的位置和尺寸。Playwright 的click默认会尝试滚动到元素位置但如果遮罩层存在它还是会失败。这时候可以加一个等待遮罩消失的前置判断或者用forceTrue强制点击慎用可能点到错误的东西。5.2 页面跳转导致的上下文丢失购票流程里经常有新窗口或者 iframe 弹出比如选座页面、支付页面。如果你的脚本还盯着原来的页面对象操作就会报元素找不到。解决办法是在每次可能发生跳转的动作之后重新获取当前的页面或 frame 上下文。# 点击后可能打开新窗口 with page.context.expect_page() as new_page_info: page.get_by_role(button, name立即购买).click() new_page new_page_info.value new_page.wait_for_load_state()这种预期某个事件发生的写法比点完之后sleep再去找窗口要可靠得多因为它是在事件真正发生时立刻捕获不会因为等待时间不够而错过。5.3 验证码与风控的边界这里必须把话说清楚验证码是平台用来区分人和程序的安全机制脚本不应该、也不建议去破解它。我遇到验证码时的处理方式是——暂停自动流程提示人工介入由我自己完成验证后再继续。这既是遵守规则也是保护账号安全的务实做法。至于风控表现为请求被拒、页面返回异常、账号被临时限制等。应对思路不是对抗而是降低异常特征控制请求频率、模拟正常的操作间隔、避免在非开票时间做无意义的轮询。一个行为模式接近正常用户的脚本本身就不容易触发风控。异常现象可能原因应对思路请求被拒频率过高降低轮询频率加随机间隔页面返回异常触发风控暂停操作人工检查账号状态出现验证码行为异常暂停人工完成验证账号被限制多次异常停止操作等待限制解除5.4 时钟不同步带来的时序偏差这个坑很隐蔽。你以为 20:00:00 开票脚本也在 20:00:00 发请求结果平台显示未开售或者晚了半秒票就没了。问题出在本地时钟和服务器时钟存在偏差。解决办法是提前用网络时间协议校准本地时间或者在脚本里加一个可配置的偏移量根据实测结果微调。我一般会在开票前做一次对时测试在非开票时间观察页面上的倒计时和本地时间的差异估算出偏差量然后在脚本里补偿。这个细节看着小但在毫秒必争的场景里可能就是成败之分。6. 让脚本更稳的几个工程习惯写到这儿流程和坑都讲得差不多了。最后分享几个让脚本从能跑进化到好维护的工程习惯这些是我做了好几个项目之后才慢慢养成的。6.1 日志要记到能复盘的程度脚本跑挂了最怕的就是不知道为什么挂的。我的做法是每个关键动作都打日志什么时候检测到什么状态、执行了什么动作、耗时多少、结果如何。日志不用花哨但一定要包含时间戳、状态、动作、结果这四个要素。出问题的时候翻日志就能还原整个执行过程比盯着屏幕瞎猜高效得多。import logging logging.basicConfig( levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s ) logging.info(检测到状态 READY_TO_BUY准备点击购买)6.2 配置和代码分离场次、票档、观演人这些信息不要硬编码在代码里。把它们抽到一个配置文件比如 YAML 或 JSON里改需求的时候只改配置不动代码。这样做还有个好处同一套代码可以复用于不同的演出只要换配置就行。# config.yaml target: session: 2024-12-31 周六 19:30 price_tier: 看台 680 attendees: - 张三 - 李四 timing: start_offset_ms: 506.3 失败要能优雅退出脚本最忌讳的是卡死——既不成功也不报错就那么僵在那儿。所以每个等待都要设超时每个循环都要设上限任何异常都要有兜底处理。宁可明确地失败退出也不要无声无息地挂着那样你连问题出在哪都不知道。我在主流程外面套了一层总的超时控制超过预定时间还没到终态就主动退出并打印当前状态和截图。截图这个习惯特别有用很多时候看一眼截图就知道卡在哪一步了。6.4 尊重规则理性使用最后这点最重要。脚本是工具工具的价值在于帮人省去重复劳动而不是用来破坏公平或者钻空子。控制请求频率、遵守平台的购票规则、遇到验证码人工处理、不恶意占用资源——这些不是技术限制而是使用者的基本素养。一个负责任的自动化脚本应该让整个购票环境更有序而不是更混乱。我在实际使用中的体会是脚本真正帮我省下的是那些反复刷新、反复确认的精力让我能把注意力放在这场演出到底值不值得看这个价位合不合适这些真正需要判断的事情上。技术是手段看演出才是目的别本末倒置了。
