2026年1月30日 · 639 字 · 2 分钟阅读

12306 自动化抢票脚本：Selenium 实战

起因

每年春运、节假日，12306 抢票都是一场玄学修罗场。手速、刷新频率、网络延迟，任何一个环节慢一拍票就没了。这个脚本就是那段时间为了不再纯靠手指敲键盘，做的一个自动化方案。

技术栈很简单：Selenium + ChromeDriver + 一些 12306 页面元素的脚本化操作。

启动 Chrome → 自动登录 → 选择车次 / 日期 / 席别
   → 轮询查票（毫秒级刷新）
   → 有票立刻提交订单
   → 弹验证码？人工接管

支持两种实现：

1. 验证码这道坎绕不过去

12306 的滑动拼图 + 文字图片验证码每隔一段时间就更新一版反爬策略。我没去硬磕识别——脚本只负责自动化前后流程，遇到验证码会暂停并提示人工介入。这是务实选择：花一周训练 OCR 不如停下来手动滑一下省事。

2. 元素定位的稳定性

12306 前端会偶尔改 class 名 / 加不可见的 wrapper 元素。脚本用了多重定位策略——xpath + css selector 兜底，单点失败概率低很多。

3. 反爬封号风险

请求频率太高会被 IP 封。脚本里加了随机间隔 sleep（300-800ms），看起来像真人手速。生产抢票时这是底线——封号 24 小时，啥票都没了。

4. ChromeDriver 版本必须匹配 Chrome

仓库里直接 bundle 了一个 18MB 的 chromedriver.exe（项目里能直接用）——但浏览器自动更新后版本对不上就会报错。换 Chrome 后记得同步换 driver。

诚实说：不一定。12306 反爬一直在升级，脚本年代越久越容易失效。这个脚本主要价值是作为 Selenium 实战参考——怎么处理动态页面、怎么应对验证码、怎么做轮询提交、怎么平衡速度和反爬。

如果你只是临时抢一两张票，官方 App 的候补功能其实够用了（不像几年前那么必须靠脚本）。这个项目更适合作为「学 Selenium 的入门参考」。

回头看，这是一个非常典型的「先解决问题、后总结模式」的产物——一开始只是为了抢票，写着写着学会了：

这些经验后来在做爬虫、自动化测试时都用上了。所以即使脚本本身可能过时，这次折腾回报远超原本的目标。