简介一套面向12306购票场景的自动化抢票脚本适合对Python爬虫、自动化操作以及验证码识别感兴趣的初中级开发者作为技术参考。压缩包共134个文件整体大小约62.84MB内容以Python源码61个py和编译生成的pyc文件48个pyc为主同时包含用于验证码识别的h5模型、Dockerfile与shell脚本等容器化部署配置以及CDN列表、代理列表、日志和说明文档。这些文件覆盖网络请求处理、登录验证、票务查询、下单支付等核心环节有助于梳理抢票脚本的完整技术链路。此外资源中还提供了png截图和jpeg图片可用于查看界面或代码展示。已有440人浏览学习。借助该包读者可以研究自动化脚本的模块划分与多文件组织方式理解机器学习模型在验证码识别中的应用并借鉴容器化部署思路。需要特别留意使用此类脚本可能违反12306使用条款并存在法律风险建议仅用于技术研究与学习。 每年春运放票那几天我的手机里总会有几个“技术流”朋友在群里发截图有人用脚本抢到了热门线路的卧铺有人凌晨守候还是两手空空。我自己也折腾过一阵12306抢票脚本说实话这东西“能不能用”和“怎么用”完全是两码事。它本质上是把人工盯着浏览器反复刷新、填表、提交的那套流程交给程序按毫秒级的速度去执行背后涉及的就是接口调用、会话管理、数据解析和频控规避这一整套东西。这篇文章我就把12306抢票脚本的完整思路和实操经验拆开讲一遍。从放票机制的原理、脚本核心模块怎么设计到放票瞬间的实战节奏、账号安全边界一次性说清楚。适合三种人看一是准备自己写脚本跑通流程的开发者二是想搞清楚第三方抢票软件为什么“时灵时不灵”的普通用户三是单纯对12306这套复杂的余票体系感兴趣的极客。1. 动手之前先把12306的放票机制说透很多人写抢票脚本第一件事就去查API、抓包这是本末倒置。你不理解12306的放票逻辑写得再快也抢不到。只有先把“票是怎么放出来的”这件事搞明白脚本才有的放矢。1.1 余票不是一次性放完的12306的放票规则里最核心的一条是余票是分阶段、分批次释放的。每趟车次在起售时间点会放出一批票但这批票不一定包含这趟车的所有运力。沿途大站会预留一定比例的票额始发站和终到站之间不同区间的票额分配也不一样。举个具体的例子北京到上海的G字头列车起售那一刻放出的票可能主要面向北京到上海全程、北京到南京、北京到济南这些热门区间。到了发车前一天到两天会有第二波票释放通常是因为某些预留区间的票没有卖完系统把剩余运力重新投入公共票池。退票回流又是一个独立的时间线尤其发车前48小时和24小时是两个退票高峰窗口。抢票脚本要做的第一件事就是在正确的时机发起查询。很多脚本抢不到票不是因为程序写得差而是起售之后过了一两分钟才启动第一波票早就被消化完了。真正的抢票窗口往往就在放票后的几十秒内。1.2 抢票脚本到底在“抢”什么从技术视角看12306抢票脚本做的事情和人工操作浏览器没有本质区别只是换了一套执行方式。完整流程拆开就是四步登录、查票、提交订单、支付。登录需要处理账号密码登录或扫码登录维护登录后的会话状态Cookie。查票向余票查询接口请求某天某区间某车次的余票信息。提交订单查到有余票后立即提交乘车人信息并锁定车票这一步会返回排队的队列位置。支付锁定车票后在规定时间通常是30分钟内完成支付脚本一般只做到提醒或自动跳转支付页面。12306官方其实提供了一套完整的HTTP接口包括余票查询、列车时刻表、站点信息等。这些接口本身就支持浏览器访问脚本只是用程序替代了手动点击。需要留意的是查询接口和数据接口一般不需要登录就能访问但提交订单必须依赖有效的登录状态。我见过不少新手脚本把大量精力花在“模拟滑动验证码”上其实对于个人小规模使用完全可以用扫码登录绕开大部分验证码问题手机扫一下就完事没必要去对抗那套行为识别模型。1.3 官方风控到底在防什么谈抢票脚本必然绕不开风控但很多人对风控的理解是有偏差的。12306的风控体系防的不是“你用程序查票”而是“你用程序短时间产生爆炸性请求量把查询服务打挂了”。网上讨论12306系统时总有一种误解好像它在和所有抢票者玩“猫鼠游戏”风控强到见脚本就封。实际上12306官方是允许第三方软件接入的早年甚至出过官方抢票补票渠道后来才逐步收敛。当前风控重点集中在几个层面单个账号的短时请求频率、同一IP来源的请求密度、下单接口的并发量、以及账号行为是否符合正常人类操作特征。理解这层逻辑后个人脚本的码率就能调了。真正的原则是“请求有节制、重试有退避、行为像真人”而不是“越快越好、越多越好”。后面我还会具体说怎么把请求频率控制在安全区间。2. 抢票脚本的核心模块按这四个方向拆明确了抢票就是在抢“正确时间的正确数据”接下来就可以拆解一个可用的脚本到底由哪几个模块组成。很多人写脚本从“能跑”就直接上线漏掉了状态管理和异常处理结果放票那一刻程序却崩了这才是最冤的。2.1 登录与会话保持登录模块是所有操作的前提。12306目前支持账号密码登录和扫码登录两种方式。对脚本来说密码登录会要求通过验证码识别这套流程对抗成本高个人使用时强烈不推荐去做验证码的破解或识别技术上既不稳定也容易踩红线。我自己的做法是脚本启动时打开一个本地浏览器窗口加载12306登录页我手动扫码完成登录然后脚本从浏览器会话中提取Cookie存入本地。之后所有的请求都带上这个Cookie直到会话过期。这里有一个关键细节Cookie的过期时间并不固定有时候几个小时有时候能稳定用一天。脚本里必须加一个“状态检查”逻辑每发起一次请求先判断返回结果是否跳转到登录页如果发现会话失效就打日志提醒重新登录而不是继续跑下去报各种奇怪的错。另外强烈建议脚本里只维护一个账号的登录态。多个账号混用同一个Cookie池或者同一IP频繁切换极其容易触发风控得不偿失。2.2 余票查询模块一次请求的完整逻辑余票查询是整个脚本最核心的模块因为你要先知道有没有票才知道要不要下单。12306的余票查询接口大概是这样的逻辑传入出发站、到达站、出发日期和车次编号接口返回每个车次每个席别的余票状态。这里的第一个坑是车站代码转换。用户输入的是“北京”或“上海虹桥”这样的中文站名但12306接口里要求的是六个字符的电报码比如“BJP”代表北京“AOH”代表上海虹桥。写代码时根本不需要自己去整理这张表12306提供了一份公开的站点名称文件脚本启动时解析一次维护成“城市名到车站代码列表”的映射就可以了。第二个坑是车次号和列车编号的区别。查询参数里需要传的是一个叫“train_no”的编号它和你在车站大屏上看到的“车次号”比如G1、D313不是一回事。查询接口返回的车次信息里会同时包含“station_train_code”和“train_no”后续下单、查详情都要用后者。拿错字段去请求结果就是提示“未找到列车”。2.3 下单与订单提交查到余票之后脚本需要第一时间提交订单。这一步涉及的数据包括乘车日期、车次编号、出发站代码、到达站代码、席别代码、乘车人姓名和证件号。乘车人信息需要预填进脚本配置里因为12306的下单接口要求传入乘客列表临时再输入时间肯定来不及。提交订单后返回的数据里通常有一个“排队人数”的字段也可能直接提示“当前排队人数过多”。这个字段非常关键它决定了你要不要等、要不要换车次。我实测下来排队人数少于100的时候大概率能订上超过500基本就没戏了这时候继续傻等不如掉头去查下一趟车次。还有一点容易被忽略下单接口并非百分百可靠偶尔会出现网络超时、连接重置。脚本必须做幂等控制也就是同一张票不要重复提交多次否则会产生多个锁定订单占住票额还可能导致支付时间重迭。一个技巧是提交订单后用订单号去查一次订单状态确认锁定成功了再进入下一步。2.4 结果通知抢到票之后的最后一环很多人觉得通知模块不重要其实这一环恰恰决定了脚本好不好用。放票时间常常是早上8点到下午6点之间你不可能时时刻刻盯着屏幕。脚本抢到票后如果只是默默写进日志你可能半小时后才看到30分钟的支付时限早就过了。我用的方案是抢到票后立即播放一段响亮的系统提示音同时通过Server酱或者钉钉机器人往手机推一条消息内容包含车次、日期、席别和支付链接。这样即使人不在电脑前也能第一时间知道“票拿到了赶紧去付款”。日志方面脚本至少要把每一次查询的时间、余票状态、下单结果记下来。这些日志不仅是排错依据还能帮你复盘“为什么没抢到”——当时是查询慢了、下单被拒还是车次压根没放票。有了这些数据下一轮抢票才有优化方向。3. 数据层准备站点表、车次表和席别优先级脚本能不能抢得快除了代码效率还有一个常被忽略的变量数据准备得够不够细。很多人喜欢在脚本里写一堆硬编码比如“北京南AOH”之类的结果换个城市就改代码。这里的数据准备工作做好一次以后春运、暑运、节假日复用起来就很舒服。3.1 城市名到车站代码的映射12306有个公开的站点文件里面是全部车站的“中文名-拼音缩写-电报码”对照表。这个文件解析之后要做的不是简单的“一个名字对一个代码”而是要处理“一个城市对多个车站”的关系。比如“北京”这个城市有北京站BJP、北京西BXP、北京南VNP、北京北VAP、北京朝阳IFP等好多站。用户在配置里输入“北京”是不够的脚本必须能列出候选车站或者由用户明确指定。更复杂的是“上海虹桥”这种带方位词的综合枢纽电报码是“AOH”和上海站“SHH”是完全不同的两个站票池相互独立抢票时要分开查。我的做法是配置文件里用一个“origin_stations”和“dest_stations”数组每个数组元素是一个车站代码。起售查询时对所有出发站和到达站的组合逐一查询。这样做的好处是能同时盯住“北京南→上海虹桥”“北京南→上海”“北京→上海虹桥”等多条路径只要其中一条有余票就能抢到。3.2 车次与席别不是所有车次都值得抢站点搞定后还要维护一张“车次-席别”的优先级表。原因很简单一趟车次可能同时有商务座、一等座、二等座、硬卧、软卧、无座等席别而你的预算和舒适度偏好决定了哪些席别是可以接受的。12306的席别代码有一套规则商务座是M、一等座是O、二等座是6、硬卧是3、软卧是4等。脚本配置里建议把席别写成一个有序数组比如“[6, O]”表示优先抢二等座抢不到再抢一等座。提交订单时按数组顺序尝试而不是一把梭把多个席别全提交那样容易订到自己不想要的票。另外要特别提醒动车的“无座”票偶尔会单独放出来价格和二等座一样如果你的脚本里席别优先级包含无座要清醒地知道这代表你愿意接受站着回家。我自己是不建议把无座放进优先席别的宁可多等一趟车。3.3 区间策略抢全程还是抢区间前面提过12306的票额是分区间的。热门线路的短途区间比如北京到天津可能起售就秒光但全程票北京到上海反而有余量。这就衍生出一个经典的操作策略选全程票、提前下车或上车补票。具体来说你想买北京到济南的票但济南是热门中途站区间票秒没。这时候你可以查询北京到上海的车次如果全程有余票就直接买北京到上海然后到济南提前下车。成本高了一些但至少能确保上车。反过来如果始发站是中间站车上座位可能从起点站就被占满这时候可以考虑买始发站到你目的地的票再在中间站上车这段路程的座位就是你的。这个策略放到脚本里实现也简单配置多个“抢票区间”每个区间独立查询、独立下单。但要提醒一句涉及“买长乘短”“中途上车”的操作要遵守12306的客规有些车次对中途上车有检票限制别等到上车才发现票被核验异常那就真的只能站回家了。4. 放票瞬间的完整复盘从查询到下单的60秒本章没什么高深理论就是一个字快。但“快”不是靠把请求频率调到最高实现的而是靠节奏设计和细节安排。我复盘过多次抢票成功的瞬间也复盘过抢票失败的过程差异点非常清晰。4.1 起售前的准备清单起售时间有确定性每个车站都有自己的放票时间通常在一段时间内固定不变。12306 App里能查到具体每个站的起售时刻脚本里建议写一个“按车站适配的启动时间表”比如北京西是上午8点、上海虹桥是下午1点半别所有车站都用同一个时间。起售前一晚要做三件事。第一把要抢的车次、席别优先级、乘车人信息、支付方式全部在配置文件里过一遍别一大早在手忙脚乱。第二跑一次完整的“模拟流程”也就是查一次真实余票、提交一个测试订单再取消确保登录态有效、下单链路通畅。这个测试订单不会真扣款锁定后会过期释放不会影响后续抢票。第三校准系统时间和12306服务器时间之间的误差直接用电脑系统时间同步NTP即可。4.2 实际抢票的节奏控制起售时间点附近我的脚本节奏是分阶段的而不是一上来就疯狂请求。起售前1分钟脚本开始低频预热先验证Cookie有效性和查询接口连通性频率控制在每10秒一次。起售瞬间到之后30秒这是黄金窗口期。此时放开查询频率到最快但也要控制在每秒5次以内并且做好随机间隔。我实测下来关键不在每秒多少次而在起售瞬间能否尽快发出第一次有效查询这决定了你排在下单队列的什么位置。查到余票后立刻下单不再继续查询。如果下单返回排队人数少等待锁定结果排队人数多马上切换下一个车次继续查。很多人失败在“贪心”上明明某个车次有余票却嫌不是最优席别想着再查一趟更好的车。结果最好的车次没等到原本能买的票也被别人扫走了。我的建议是第一轮放票时先锁住可接受的票支付前再观望要不要更换别在查询阶段做选择。4.3 实测案例分析我去年春运帮朋友抢过一趟北京到武汉的高铁出发日期是年前第五天。放票时间到了之后脚本查询到G69次有一等座余票3张但二等座余票0张直接提交了一等座的订单排队人数12一秒锁定成功。同期另一个朋友用类似脚本抢沈阳到哈尔滨他配置时把所有车次都列上了但没设置席别优先级结果脚本优先提交了几趟无座的票他看消息晚了支付了一张无座上车之后那叫一个后悔。这两个案例说明两个问题一是脚本里每个策略都要提前通过配置定义清楚不要留到抢票瞬间让程序“临场发挥”二是优先席别梦想和现实之间要做取舍放票高峰期“能上车”永远比“完美舒适的席别”更重要。5. 别让账号被拉黑风控与合规使用的边界这一章其实比技术实现更值得讲因为抢票脚本一旦使用不当轻则账号被限制购票重则把自己送进法律风险区。我见过不少人在网上求“多账号并发抢票”方案这种思路从一开始就是错的。5.1 账号安全优先个人用脚本抢票一个账号就足够了。12306的账号体系是实名制绑定的一个账号可以添加多个乘车人帮父母、伴侣一起抢完全没毛病。如果你真的需要同时抢多个人的票用同一个账号下单一次锁多张票就行。千万别做的事同一个IP下开多个账号并发抢票。这种操作的特征非常明显系统很容易识别并限制相关账号的购票功能。也别用脚本去刷“候补”队列候补本来就是官方优先处理通道你脚本刷得再快也插不了队反而增加账号风险。请求频率方面我再强调一次宁可慢一点不要太快。你的目标是放票瞬间比别人快一步不是在整个放票窗口期把自己变成持续高并发的肉鸡。一旦被限制抢票周期内基本就废了。5.2 合规意识脚本是查询工具不是黄牛工具说句掏心窝的话12306抢票脚本最大的价值是帮你省去手动刷新、反复填表的时间是在“人人平等拼手速”的游戏里给你一个公平的工具。但任何工具都有被滥用的可能脚本也一样。不允许做的事情包括但不限于使用脚本帮陌生人有偿代抢车票、批量注册账号、囤积车票后加价转售、干扰12306系统的正常运营。这些行为不只是违反平台规则还可能触犯法规。清醒一点抢票脚本的合规边界就是“服务于自己和家人朋友的出行刚需”超出这个边界技术再酷也不值得碰。另外现在12306官方已经把候补购票功能做得相当成熟很多时候候补的成功率比你自己脚本抢还高。脚本不是万能的它只适合在放票瞬间的短时间窗口内争夺“首轮放出的票”一旦错过了那个窗口乖乖去开候补反而更靠谱。5.3 什么时候用脚本什么时候该用官方候补根据我自己这几年跑脚本的经验我总结了一个选型逻辑直接放这里节假日首日发车的热门线路、热门时段脚本有优势因为首轮放票的大量票是拼手速秒抢的脚本能把你的人工点击延迟压缩到几十毫秒。不是首日发车、不是热门时段不一定值得上脚本官方候补的优先级已经很高。发车前1-2天的临时余票和退票回流脚本持续查询有效但官方候补也在同时工作两个通道可以并行。长途区间票源紧张、短途区间有余票用脚本配合“分段抢票”策略更灵活可以多区间同步盯。这套逻辑理论上也适合其他买票平台但12306的特殊性在于实名制、一证一票、退改签规则复杂第三方脚本能操作的空间其实比其他平台小得多。所以我的结论很明确脚本是工具候补是后盾两者不是替代关系而是配合关系。跑通自己的抢票脚本之后我反而没那么依赖它了。这两年春节买票我很多时候会先用官方候补挂上然后在发车前那几天用脚本做低频率的余票监控捡漏的概率反而不低。说到底抢票这事拼的是“合理预期 多通道并行 决策果断”脚本只是帮我把这三点执行得更彻底而已。本文还有配套的精品资源点击获取