Java自动抢票工具拆解：验证码识别与无人值守下单链路解析

简介：对Java程序员而言，12306抢票是一场典型的高并发实战演练。这份资源以图文教程形式记录了程序员版抢票程序的完整使用过程，从JRE环境准备、start.bat启动、账号登录到自动查询、验证码识别、指定车次与卧铺/动车优先等配置项均有截图说明，还附上原作者对反编译源码的分析思路，适合想在真实场景中了解自动化购票工具设计与使用的开发者。包体仅1个doc文件，约467KB，以文字和截图承载操作流程与排错要点，轻量但信息密集。目前已有700人学习下载，尤其适合对Java网络请求、HTML解析及验证码识别感兴趣的读者参考，也可作为春运购票的应急辅助。

1. 先说一个反直觉的结论：验证码识别只有一成准确率，却能稳定提交订单

先说一个反直觉的结论：一个验证码自动识别只有一成准确率的程序，却能在放票后两分钟内提交成功订单。号称“秒杀12306”的这个 Java 项目，靠的不是单次识别率，而是整条无人值守链路：验证码错了就重新获取，登录失败就反复重试，查不到票就自动刷新，直到订票成功的弹窗弹出来。它解决的，正是 12306 网络购票上线初期页面超时、登录排队、验证码看不清导致人工刷新抢不过机器的痛点。程序依赖 JRE 1.6 以上，双击 start.bat 就能启动，填入账号密码后自动跑完登录、查询、下单。想拆解网页自动登录和自动提交订单的开发者，这个项目很适合作为起点。

2. 技术选型与整体架构：JRE 1.6 之上，脚本加配置驱动的自动购票链路

2.1 程序骨架：start.bat、config.properties 与 jar 包的三层分工

从这个项目压缩包解压出来的内容来看，布局非常朴素：一个 start.bat、一个 config.properties、一个 jar 包，外加一份使用说明.txt。没有 Maven 结构，没有源码目录，甚至没有像样的 Readme，一眼就能看出这是早期个人项目直接分发二进制包的风格。但打开使用说明你会发现，这种朴素正是它的设计逻辑——最终用户只需要改配置文件和双击脚本，根本不需要跟代码打交道。

start.bat 承担启动任务，内部逻辑通常不超过五行：检查 java 命令是否存在，调用 java -jar 指向主程序。config.properties 承担参数外置，用记事本就能编辑，里面可以设置网络连接参数、指定车次、开关自动识别验证码等。jar 包则是业务核心，把登录、查询、下单、提醒四条链路全部封装在 Java 类里。三层各司其职，改配置不需要重编译，换业务逻辑也不需要动启动脚本，这是 Java 桌面工具里非常标准的分层。

从工程复用角度看，这种布局给二次开发留出了非常清晰的入口。想改登录逻辑，直接反编译 jar 找登录类；想改默认车次，直接编辑 config.properties。当年不少同类项目把配置写死在代码里，用户每换一次环境就要重新求作者改包，而这个项目一开始就避开了这个坑。

环境要求是 JRE 1.6 以上版本，这对今天的开发者来说几乎不是门槛，但在当时很多用户连 Java 是什么都不清楚。原作者的建议是用系统软件管家搜索“Java”并安装 Java Runtime Environment 6 Update 30，对已有 JDK 的人来说就完全不用操心了。下面是 start.bat 的最小实现形态：

@echo off java -jar train-catch.jar pause

这段脚本唯一的职责是启动主程序。pause 命令保证如果程序异常退出，命令行窗口不会瞬间关闭，用户能读到错误信息。更健壮的写法会加上 java 命令探测和常见安装路径兜底，例如在 PATH 中找不到 java 时去系统安装目录下寻找。如果你拿到类似的启动脚本后点开即闪退，优先怀疑对象就应该是这个 bat 里的 java 路径，而不是程序本身。

2.2 页面解析与自动交互：htmlunit 模拟浏览器、htmlparse 抽取页面节点

这个项目最值得拆的技术决定，是没有做成浏览器插件，而是用 Java 直接模拟 HTTP 请求来完成整个购票流程。登录时要提交表单、查询时要拼接参数、下单时要维持会话，每一步都需要程序自己理解页面结构并做出响应。这样一来，项目的技术核心就变成了两个库的配合：htmlunit 负责模拟浏览器行为，htmlparse 负责解析返回的 HTML 内容。

htmlunit 在 Java 生态里是很经典的浏览器仿真工具，支持 Cookie 管理、JavaScript 执行、表单自动提交，常用于网站自动化测试和爬虫场景。这个项目用 htmlunit 模拟的就是“打开登录页、填写账号密码、提交登录表单、拿到会话 Cookie”这一段操作。因为在 12306 网络购票系统上线初期，并没有对开发者开放稳定的 API，自动购票的唯一路径就是以浏览器身份去请求页面并解析响应。

htmlparse 则负责把响应里的 HTML 转成可遍历的结构，程序从解析结果中抽取车次编号、余票数量、出发到达时间这些关键字段，再交给后续的决策逻辑处理。两者配合的代码结构大致是这样：

// 用 htmlunit 发起登录请求并保留会话 WebClient client = new WebClient(); client.getOptions().setJavaScriptEnabled(true); client.getOptions().setCookieManager(cookieManager); HtmlPage page = client.getPage("https://dynamic.12306.cn/otsweb/"); HtmlTextInput user = page.getElementByName("loginUser.user_name"); HtmlPasswordInput pass = page.getElementByName("loginUser.password"); user.type(username); pass.type(password); // 提交表单后，用 htmlparse 解析登录结果 Document doc = Jsoup.parse(page.asXml()); Element result = doc.selectFirst(".login-success");

这里演示的是登录环节的最小逻辑：先用 htmlunit 的 WebClient 打开登录页，通过元素名找到用户名和密码输入框，填入内容后提交表单，然后用 htmlparse（示例里用 Jsoup 代替）解析返回页面，判断是否出现登录成功的特征节点。setJavaScriptEnabled(true) 是关键的开关，很多购票页面依赖 JS 动态渲染表单，关掉就会因为找不到元素而报错。

这套方案的优点是不依赖具体浏览器版本，Java 进程本身就能完成一切；缺点也同样明显——程序绑定的是页面结构而不是稳定的接口，12306 前端稍有改版，解析逻辑就可能全部失效。这也是几乎所有同类抢票脚本生命周期都很短的原因。二次开发时最好把页面上所有字段名、选择器集中封装起来，页面一改版只需要替换一个配置类，而不是满项目查找。

2.3 验证码识别的实现路径：颜色像素与模板匹配的朴素做法

验证码识别是这个项目最出圈的模块。原作者没有引入 OCR 库，而是用了一套毫不花哨的像素处理方案：把验证码图片读进内存，根据颜色阈值做二值化，把文字和背景分开，再按像素密度切割出单个字符，最后和内置的字符模板做匹配。用代码来写就是：

// 读取验证码图片，按灰度阈值分离前景和背景 BufferedImage image = ImageIO.read(captchaStream); int threshold = 128; for (int x = 0; x < image.getWidth(); x++) { for (int y = 0; y < image.getHeight(); y++) { int gray = image.getRGB(x, y) & 0xFF; if (gray < threshold) { pixelMap[x][y] = true; // 判定为文字像素 } } } // 按列统计像素密度，定位字符边界，与模板逐一比对

threshold 是二值化阈值，控制哪些像素算文字、哪些算背景。调得太低会把干扰线和噪点都当成文字，调得太高又会抹掉字符细节，这个参数必须根据验证码的实际样式反复测试。原作者提到自己按颜色像素来识别验证码的思路，但验证码上叠加了模糊效果，所以效果并不理想。

程序给出的应对方式非常务实：不追求识别准确率，而是靠重试次数来弥补。自动识别失败后，程序会重新获取验证码图片，再走一次像素匹配流程，直到某次成功为止。原帖明确说“验证码可能十次里只有一次是对的”，但配合无人值守运行，仍然能在一两分钟内完成登录。这种“低单次成功率 + 高重试频率”的组合，在资源受限的场景下反而比追求单次精度的方案更稳定。

从学习角度看，这个模块的价值不在算法多高明，而在于它演示了图像识别最朴素的思想：灰度化、二值化、字符分割、模板匹配。后来者如果想把验证码识别率做上去，可以沿着这个骨架替换成特征提取或深度学习模型，但流程骨架基本不用动。

2.4 绑定登录状态与双通道提醒：订票成功到人工支付的交接设计

自动化链路跑得再顺，最后一步支付还是得交给用户，因为支付涉及银行跳转和网银验证，自动化不但复杂而且风险高。于是程序做了一个非常清晰的边界设计：订票成功后立刻弹窗提醒，然后终止自动操作，把后续动作交给人工完成。这个边界不是随手画的，而是考虑了 45 分钟支付窗口和支付页面多级跳转两个现实约束。

程序在订票成功时的提醒方式做了浏览器适配：在 Chrome 下有右下角提示和声音提醒，在 Firefox 下是桌面弹窗，声音暂不支持。原作者没有强行统一两个平台的通知格式，而是各自实现，并且把能力差异明确标注出来。这个取舍背后是兼容性设计里很常见的思路——保留能力弱的一端，也不能因为一端做不到就把功能整体砍掉。

除了通知，程序还有一个隐含设计值得提：它鼓励用户启动程序后自行在网页端登录一次并保持在线。这样做的好处是提前占住一个会话，等程序订票成功后立刻切到网页完成支付，省去重新登录网站的排队时间。这条建议实际上把程序和浏览器两条链路并行了起来，用双会话降低最后一步的时间成本，属于非常实战的设计。

3. 核心模块拆解：从配置到订票成功的完整链路

3.1 登录模块：自动填充、失败重试与验证码等待策略

登录模块是整套流程的第一道闸门，做得不够稳，后面全是空谈。它的完整动作序列是：打开登录页、检查本地是否保存过账号密码、自动填充表单、定位光标到验证码输入框、提交登录请求、判断登录结果、失败则自动重试。整个序列里只有“等待验证码输入”这一步是真正的阻塞点，用户要么人工输入，要么开启自动识别让程序自己碰运气。

自动重试是这个模块的核心竞争力。登录失败通常有两种原因：一是网络繁忙导致连接超时，二是验证码识别错误被服务器拒绝。针对两种情况，程序的处理都是重新加载登录页、重新填充信息、重新提交，直到成功。注意这里的重试不是简单地把上一次请求再发一遍，而是重新走一遍“打开页面、填充表单、提交请求”的完整流程，因为服务器端的会话状态可能已经变了。

一个需要重点注意的设计是“密码明文记录在 Cookies 里”。这个选择解决了“自动填充”的需求，却在安全上留下了口子：在公用电脑上，任何打开浏览器开发者工具的人都有可能翻到明文密码。原作者在说明里也特别提醒，非自己的电脑不建议记录登录信息。这个取舍在当年很常见，放在今天看更应当作反面案例。二次开发时建议把密码存储换成本地加密仓库，或者至少做一次简单混淆。

登录成功后的处理同样重要。程序会把登录成功的会话状态保存下来，供后续查询模块使用，并且在界面上给出明确的登录成功提示。如果开启自动识别验证码，用户在这一步几乎不需要做任何事，程序会自己反复尝试直到进入下一环节；如果是手动模式，则需要盯着界面的验证码输入框尽快完成输入。两套模式适合完全不同的场景，前者适合无人值守，后者适合人坐在电脑前抢速度。

3.2 查询模块：线路记忆、自动刷新与余票判断

登录成功之后，程序自动进入查询阶段。这个阶段的第一个贴心功能是线路记忆：程序自动记录上一次查询的出发地、目的地、出发日期，下次启动时自动填入，省去重复输入的操作。这个功能在代码层面通常就是一组字符串缓存在配置文件或者内存里，实现很简单，但对用户体验的改善非常直接。

查询的核心机制是循环轮询。程序按照设定好的时间间隔，反复向 12306 发起余票查询请求，把返回的车次列表和用户设定的条件做比对。如果当前没有符合条件的车次，程序会等待一个间隔后自动重新查询，而不是停在原地。这个自动刷新机制就是抢票成功率的关键——高峰期余票放出的窗口期只有几分钟，靠人工刷新很难随时盯住，程序可以做到秒级甚至更短间隔的持续关注。

查询条件的比对逻辑大致是这样：

// 轮询余票接口，命中条件后触发下单 while (!stopFlag) { List<Train> trains = queryRemainTickets(from, to, date); for (Train train : trains) { if (passPriorityFilter(train)) { submitOrder(train); // 进入下单流程 stopFlag = true; break; } } Thread.sleep(pollIntervalMillis); }

stopFlag 是全局状态位，保证只要有一个车次进入下单流程，轮询立刻停止，避免并发提交重复订单。pollIntervalMillis 是刷新间隔，调得太短会触发 12306 的风控机制，调得太长又会错过余票放出的时间窗口。原作者在文档里虽然没有给出具体数值，但经验上三到五秒是一个相对稳妥的区间。passPriorityFilter 则对应前面提到的优先级策略：指定车次、动车优先、卧铺优先都会在这个过滤器里实现。

这个模块的另一个细节是查询失败的处理。网络抖动导致查询请求超时时，程序不会直接把异常抛给用户终止运行，而是当作一次未命中继续下一轮轮询。这个设计保证了长时间运行时的稳定性，也是无人值守模式能成立的前提。

3.3 下单模块：自动提交订单直到成功的重试闭环

查询命中只是第一步，真正决定成败的是下单。原项目 1.1 版本最重要的更新就是“自动提交订单，直到订单成功”，这句话是整个下单模块的纲领。查询模块可以容忍失败重试，下单模块同样如此——提交订单失败时，程序会重新发起下单请求，直到服务器明确返回订单成功。

下单模块的内部流程比登录更复杂：提交车次和日期信息、确认乘车人、确认订单并提交、等待服务器返回订单号。每一步都可能因为网络波动或会话过期而出错，因此程序需要处理的不只是“请求失败重试”，还包括“请求成功但响应异常”的情况。严谨的做法是给每次下单请求生成一个唯一标识，根据服务器的响应去判断到底是成功、失败还是未知状态，避免重试时重复创建订单。

订单成功后的动作是程序与人工的交接点。程序弹窗提醒用户订单已生成，然后停止所有自动操作。用户接到的任务非常明确：在 45 分钟的支付窗口内，登录 12306 网站进入“我的订单”完成支付。原作者在文档里特别强调，抢票高峰期重新登录网站本身就很困难，所以要在收到弹窗后立刻行动。这也是为什么程序建议用户在抢票期间自己也在网页端保持一个登录会话——为最后一步支付节省时间。

从代码结构看，下单模块与登录模块、查询模块在类层次上是分离的，这种模块划分让每个环节都能独立替换和升级。比如你想改一下下单时的乘车人选择逻辑，只需要动订单相关的类，完全不需要碰登录和查询代码。

3.4 优先级策略：指定车次、动车优先与卧铺优先的执行顺序

不少第一次用这个程序的人会误会优先级参数，以为指定了某个车次，程序就只会抢这一趟。实际上 traincode 参数的真实语义是“优先”，而不是“唯一”。程序会先尝试预定指定车次，如果该车次无票，会自动选择其他有余票的车次继续下单。这个“优先而非唯一”的设计思路，本质上是在用户意愿和购票成功率之间取了一个折中——正因为跳出了“非此不买”的执念，整个程序的命中率才能维持在高位。

动车优先和卧铺优先也是同样的思路。动车优先表示查询结果中动车组车次会排在候选列表最前面，优先进入下单流程；卧铺优先则把硬卧席别排在最前面。这两个选项同样不是硬性约束，如果动车无票、卧铺无票，程序会退而求其次选择普通车次或其他席别。

优先级策略在代码层面大概率就是一套排序加过滤的组合。程序先按照用户指定的优先级规则对车次列表排序，再按席别偏好对余票信息排序，然后从排序结果的第一个组合开始尝试下单。如果第一个组合没票，就依次往后尝试。这套逻辑的优点是灵活，适应不同地区、不同出行习惯的用户，又不需要为每一种偏好单独写一套下单代码。

界面上的这几个选项在程序启动后也可以随时修改，而且马上生效，唯一不能改的是登录信息。也就是说，用户不用因为临时改变主意而重启程序，这在紧张的抢票场景里非常实用。

4. 运行与配置实操：从环境准备到五分钟跑通第一张票

4.1 环境准备：JRE 1.6 的安装与验证

运行这个项目的第一件事是确保有 Java 运行环境。程序是纯 Java 编写，启动依赖 jre，版本底线是 1.6。如果你的电脑上已经装了 JDK，那 jre 几乎必然存在，直接跳到下一步；如果完全没装过 Java，最快捷的方式是用系统自带的软件管家或类似工具搜索“Java”，安装 Java Runtime Environment 6 Update 30，安装过程基本上就是一路下一步。

安装完成后，验证一下环境是否就绪。在命令行输入 java -version，看到版本号大于等于 1.6 输出，即可认定环境满足要求。这里有一个容易踩的细节：如果同时安装了多个版本的 JDK，系统 PATH 里指向的可能不是你想用的那个版本。输入 java -version 确认版本无误比直接双击 start.bat 更稳妥。

配置网络放行也是一个常见的隐藏步骤。有些安全软件会默认拦截未知进程的网络请求，导致程序界面正常但一直卡在登录阶段，日志里全是连接超时。解决办法是在防火墙或安全软件里把 Java 进程加入放行名单。这一步不会写在使用说明里，但实际部署时经常是唯一的拦路虎。

环境准备全部做完，双击 start.bat，程序开始初始化 GUI 主界面。初始化的过程通常只需要几秒钟，如果双击后窗口一闪而过，回到命令行执行 java -version 定位原因。如果 java 命令本身没问题，再去排查 start.bat 里写死的路径是否和实际安装路径一致。

4.2 界面参数填写：从账号密码到动车优先与卧铺优先

GUI 界面初始化完成后，可以看到一组表单字段：12306 账号、密码、出发地、目的地、出发日期，以及几个策略开关。账号密码是登录凭据，填写后会被程序记录到 Cookies 中用于自动填充。出发地和目的地这两项在首次查询后会被自动记忆，下次启动时自动填好。

策略开关包括自动识别验证码、动车优先、卧铺优先三项。自动识别验证码对应无人值守模式，勾选后程序会在验证码环节自行循环尝试，不需要人工参与。动车优先和卧铺优先用于影响候选车次的排序权重，在没有指定车次的情况下，这两个选项直接决定程序会优先选择哪一类车票。

填写这一步大概率两分钟就能完成。填好之后点击开始，程序会按部就班地执行登录、查询、下单三条链路。运行期间界面上会持续输出当前状态：登录中、登录成功、正在查询、正在提交订单。如果开启自动识别验证码，还会看到反复出现的验证码重试提示——这属于正常工作节奏，不用怀疑程序卡死。

界面栏位之外的参数可以通过 config.properties 修改，包括指定车次和网络连接参数。界面上能改的在程序运行中即时生效，配置文件里改的需要重启程序。理解这个差异能省掉不少排查问题的时间。

4.3 config.properties 参数详解：指定车次与自定义网络连接

config.properties 是一个纯文本配置文件，用记事本打开即可编辑。里面包含的配置项不多，但每一项都直接关系到程序能不能匹配到实际环境。下面把最常用的几个参数整理成表：

userproxy 的适用场景是用户所在网络需要经过特定中转才能访问目标网站的网络环境。把它设为 true，再填入 ip 和 port，程序在发起请求时就会按照这里的地址和端口走。如果不需要这种自定义连接，保持默认的 false 即可，不需要做任何修改。

traincode 是使用频率最高的配置项。填写格式是纯车次编号，例如 D105 或 K1024。注意这里只填编号本身，不要加“车次”或“次”这样的汉字。程序会把该车次作为优先候选，但不会锁定它——没有票时会自动选择其他车次。如果你希望严格只买这一趟车，这个项目本身是做不到的，需要二次开发。

配置文件的解析通常比较脆弱，最容易出问题的是多余空格或全角字符。用记事本修改时，不要在等号两边加空格，也不要把数字写成中文全角数字，否则解析结果会是空值，程序表现就是“指定车次没生效”。改完之后重启程序再观察，比在运行中改动更容易确认是否生效。

注意：traincode 里多一个空格、半角冒号写成全角冒号，都可能导致指定车次匹配失败。改完配置后先在命令行下用记事本重新打开确认内容，再启动程序。

4.4 运行中的状态观察与订票成功后的支付流程

程序运行期间，界面上会有动态状态输出。从上到下依次能看到登录、查询、下单三个阶段的进展。登录阶段如果反复出现验证码识别失败提示，说明自动识别模式正在循环重试，不要中断它。查询阶段的提示会周期性刷新，每次刷新代表一次余票查询请求已发出。下单阶段的提示出现后，基本就进入最后冲刺了。

收到订票成功弹窗的那一刻，动作要快。打开浏览器登录 12306，进入个人中心或订单管理页面，找到待支付订单，核对车次、日期、席别、乘车人信息，然后按下支付按钮完成支付。这个过程完全在浏览器里进行，程序不参与。原作者经验里最紧张的环节就是这 45 分钟支付窗口，因为抢票高峰期重新登录网站本身就要排队。

有一个实用建议值得记住：程序开始跑之后，自己在网页端也登录一次并保持在线。这样订票成功的弹窗出现时，网页端的会话还是活的，可以直接进入订单页面完成支付，不用重新走登录流程。这相当于用双会话把最后一步的时间成本压缩到最短。

运行过程中如果发现界面参数需要调整，比如突然想换一个出发日期，直接在界面上修改对应字段即可，程序会在下一轮查询中应用新参数。只有 config.properties 里的修改需要重启程序，这层区别在文档里被特别标注过。

5. 避坑与排查：抢票工具使用中最容易翻车的五个场景

5.1 验证码自动识别准确率太低，程序一直停在登录阶段

现象是程序启动后长时间停留在登录环节，界面不断刷新验证码识别失败的提示，登录成功率趋近于零。原因在于验证码图片的干扰线和字符粘连让像素匹配模板的准确率骤降，尤其当验证码样式升级后，旧模板基本完全失效。解决方法是切换到手工输入验证码模式，或者继续使用自动识别但接受更长等待时间。自动识别的优势本就不在准确率，而在无人值守的持续尝试能力，如果人就在电脑前，手工输入的速度反而更快。

5.2 双击 start.bat 后窗口一闪而过，程序没有任何界面

这是 JRE 缺失的典型症状。start.bat 调用 java 命令时发现系统没有安装 Java 运行环境，启动过程在瞬间结束。解决步骤是先打开命令行执行 java -version，确认 java 命令是否存在并输出版本号，如果提示找不到命令，安装 JRE 1.6 及以上版本后重新执行。如果 java 命令存在但 start.bat 仍然闪退，检查 bat 文件里写死的 java 路径是否和实际安装路径一致，在自定义安装目录的场景下，路径不匹配是常见原因。

5.3 程序运行正常但一直查不到余票，更谈不上下单

分两步排查。第一，确认查询条件是否正确填了可购日期，春运期间不同车站、不同车次的放票时间不一样，在放票时间之前查询无余票是完全正常的，可以先用自己的账号在浏览器里手动查一遍同一个日期，确认服务器端确实有余票放出来。第二，检查查询刷新间隔是否过短，请求太密集会触发服务端限制导致 IP 被临时挡掉。常见做法是适当调大刷新间隔，三到五秒是比较稳妥的选择，既不至于漏掉余票窗口，也不会被服务器判为异常流量。

5.4 密码明文记录在 Cookies 里，公用电脑上有泄露风险

这个现象属于安全设计上的历史遗留问题。程序为了做到打开登录页自动填充，把用户名和密码明文写进了 Cookies。自己的私人电脑上没有太大问题，但如果是在公用电脑或借来的电脑上运行，离开前务必清除浏览器历史记录和 Cookies，或者直接在界面上关闭密码记录功能。原文档中的原话是“如果不是你自己的电脑，建议不要记录”，这个提醒到今天依然适用。二次开发时可以改成加密存储，或者至少对密码做一层简单混淆，不要让明文直接躺在 Cookie 文件里。

5.5 指定车次没有票，程序却迟迟没有切换到其他车次

这不是 bug，而是对 traincode 参数的理解偏差。traincode 的语义是“优先”而不是“唯一”，当指定车次无票时，程序理论上会自动选择其他车次，但这个自动切换不是实时的，它发生在下一轮查询命中之后。如果等了多个刷新周期仍然没有动静，需要检查 config.properties 里的 traincode 是否填写了多余的空格，或者车次编号是否与官方显示完全一致，例如 D105 误写成 D105 加一个空格。配置文件解析往往对空格和全角符号非常敏感，这类小问题常常是查不到票据的真正原因。

6. 二次开发思路：从反编译到你的专属抢票工具

6.1 用 jd-gui 反编译 jar 包，先梳理调用链

拿到 jar 包后的第一步是反编译。用 jd-gui 还原出可读的 Java 源码，在主入口类里找到 main 方法，沿着调用关系画出登录、查询、下单、通知四条链路的走向。标注出每个模块的入口类和关键方法，后续所有改动就都有了坐标。动手改之前先确认哪些类是主链路必需的，哪些只是辅助工具，避免改错地方导致启动失败。

6.2 提升验证码识别率：把像素匹配替换成轻量 OCR

原作者用颜色像素做模板匹配，准确率上限摆在那里。要改进，可以先保存几十张验证码样本，人工标注好字符后按简单模板分类，再引入轻量 OCR 库做训练和识别。替换时保持模块的输入输出接口不变，直接替换实现类即可。这个思路不仅适用于验证码，也是不少爬虫项目升级识别能力的通用路径。替换完成后需要验证的只有一件事：识别率上升了多少，单次识别耗时的增加是否在可接受范围内。

6.3 扩展多车次多日期：从单查询到并发轮询

原程序一次只查一个日期、一组车次组合，在热门线路上并不到位。可以扩展成一个轮询任务队列，把多个日期、多个车次组合放进队列，由几个并发线程分别执行查询任务，命中任一组合就触发下单。下面是一个线程池版本的骨架代码：

// 多任务并发查询，多线程同时轮询不同日期与车次组合 ExecutorService pool = Executors.newFixedThreadPool(3); for (Task task : taskQueue) { pool.submit(() -> { if (!orderCompleted.get()) { List<Train> trains = queryRemainTickets(task); Train target = pickBestTrain(trains); if (target != null && orderCompleted.compareAndSet(false, true)) { submitOrder(target); } } }); }

orderCompleted 是 AtomicBoolean，用来保证多个线程同时命中时只有一个能真正提交订单，其他线程立刻放弃。taskQueue 里的每个任务对应一个日期与车次组合，线程数并不是越大越好，请求太密集会触发服务端风控，三个线程是一个相对均衡的开始点。扩展完成后要验证两件事：一是多个任务并发时没有重复订单，二是风控触发时任务能降级重试而不是崩溃退出。

6.4 一个值得记住的边界习惯

拆完这个项目，真正让我记到现在的不是验证码算法，也不是重试机制，而是它对“哪些步骤交给程序、哪些步骤必须交还给人”的边界划分。登录、查询、下单都可以自动，最后的支付却留给了人工。这不是偷懒，而是清楚地知道支付环节涉及的第三方流程和资金风险不适合自动化。从那以后，我每写一个自动化工具都会先画一条人与程序的分界线，定义清楚哪些操作允许无人值守、哪些操作必须有人确认，边界定了再动手写代码。希望帮到你。

本文还有配套的精品资源，点击获取