简介这是一套基于JAVAEE的学生火车票订票系统项目面向学习Java Web开发的学生以及需要完成课程设计或毕业设计的开发者。项目围绕学生购票场景实现了车次查询、在线预订、后台订单管理、学生寒暑假半价优惠和团购折扣等功能可以解决从用户选票到管理员维护列车信息的完整业务需求。压缩包共包含318个文件大小约为24.27MB其中以依赖库、源码文件、编译字节码、动态页面和数据库脚本为核心并有样式表、脚本和图片等前端资源目录结构完整方便导入开发工具直接运行与二次改造。该资源已有3247人学习下载。通过运行和学习这套代码读者可以得到一套可用的订票系统源码和数据库初始化脚本具体了解Servlet、JSP、Spring、MyBatis在实际项目中的配合方式也能够体会从需求分析、数据库设计、编码实现到测试部署的完整开发流程适合作为实训项目、课程设计或毕业设计的起点。 如果要在JavaWeb课程设计里选一个“不会出错又拿得出手”的题目我第一个推荐学生火车票订票系统。这个题目我前后带过几个学弟学妹做自己也完整重写过一版它最大的好处是业务逻辑真实但不复杂学生、车次、订单、余票这些概念大家都熟悉不需要解释需求可以直接把精力花在代码和数据库设计上。对于想巩固Java基础、JavaWeb、MySQL这套技术栈的人它是一个特别合适的练手载体。我见过太多人一上来就选图书管理系统、学生信息管理系统做完之后除了增删改查几乎没有能拿出来讲的东西。火车票订票系统不一样它天然带状态流转、库存扣减、并发控制这些真实业务问题做完之后不仅代码能跑答辩、面试也都有故事可讲。下面我把整个项目的设计思路、核心代码和踩坑过程完整梳理一遍希望对正在做类似题目的朋友有帮助。1. 为什么我推荐把“学生火车票订票系统”当作Java练手项目1.1 业务场景真实需求不需要额外解释火车票订票流程其实人人都懂查车次、看余票、下单、支付、出票再加退票和改签。作为一个课程设计或者练手项目它的优势在于业务规则足够真实又不会像电商系统那样复杂到失控。我做这版项目的时候最开始也想过做图书管理系统后来发现那些题目太“平”了做完没有成就感。火车票订票不一样它的状态多边界情况多同一趟车在不同日期余票不同订票后没支付会占用余票退票要释放余票这些都是真实世界中每个人都能理解的需求。需求不用解释意味着你的精力可以全部放在技术实现上这是练手项目最该有的样子。1.2 一套系统覆盖JavaWeb全链路知识点这个题目不是只能练JDBC而是能把JavaWeb的知识点串成一条线。我大概梳理了一下功能模块和技术点的对应关系系统功能对应技术点注册登录、验证码Controller、Session、Cookie、Filter拦截器车次查询、余票列表MyBatis/JDBC、SQL条件查询、Java集合排序提交订票订单事务控制、并发安全、状态流转数据校验、异常提示参数校验、全局异常处理后台车次维护基础增删改查、日期和时间处理如果你用的是传统JSPServlet可以顺便复习Java基础、集合、JDBC、连接池如果你用Spring Boot还能接触到依赖注入、事务管理、统一异常处理、参数校验。一个项目做完相当于把Java面试里常问的集合、异常、多线程、事务这些“八股文”全部落地跑了一遍。别小看这一点很多东西光看面试题是记不住的写一遍代码比背三遍都管用。1.3 难度可控能做出“亮点”这类题目的另一个好处是难度梯度好。入门阶段可以只做基本CRUD系统能跑通中期可以加事务、加并发控制模拟抢票再往后还能接Redis缓存、消息队列做成一个分布式场景的小Demo。也就是说不管你是刚学完Java基础的学生还是准备面试的求职者都能在这个题目里找到适合自己的深度。我见过不少同学拿这个题目去参加课程设计答辩因为业务讲起来通俗代码里又有东西可以深挖评委老师问事务、问并发都能答得上来。这比做一个界面华丽但逻辑简单的管理系统更有说服力。2. 从购票到退票系统功能模块与角色权限怎么划分开始设计系统时不要急着写代码先把角色和功能边界理清楚。火车票订票系统不是只给一个人用的至少要有学生端和管理员端再加上后台自动处理逻辑。2.1 三类角色和权限边界学生用户负责注册、登录、查询车次、提交订单、模拟支付、退票、查看个人订单。学生端不需要提供修改价格、删除车次的能力这些属于管理端权限。管理员负责管理车次信息、管理学生账号、查看所有订单、统计每日售票情况。管理员看到的订单范围是全量的学生只能看到自己的订单。系统角色没有登录入口负责处理超时未支付订单、定时释放座位。从实现角度看最简单的做法是基于Session做登录拦截未登录用户只能访问首页和查询接口提交订单、退票这些操作必须在Filter或拦截器里校验登录状态。管理员接口再单独加一个角色判断。这个权限模型虽然简单但已经能覆盖需求。2.2 功能模块拆解用户模块注册、登录、退出、密码修改、个人信息维护。车次模块车次列表、按出发地和目的地查询、按日期查询、车次详情。订票模块选择车次和日期、提交订单、模拟支付、取消未支付订单。退票模块申请退票、恢复余票、退票记录。后台管理车次增删改、学生账号管理、订单查询与统计。辅助模块分页、验证码、异常提示、操作日志。功能模块不需要做得很花哨但每块功能要能讲清“输入—处理—输出”。比如订票模块的输入是车次ID、乘车日期、乘客姓名处理过程是校验余票、扣减库存、生成订单输出是订单号和一个待支付状态。把每个模块都按这个思路理一遍写代码时就不会东一榔头西一棒槌。2.3 订票和退票的业务流程订票流程我建议设计成六步学生输入出发城市、目的城市、乘车日期。系统根据车次经停关系查询可用车次。学生选择车次、座位类型提交订单。系统锁定余票注意这一步不是直接出票。跳转到模拟支付页支付成功后订单变为“已支付”。管理员后台可以给已支付订单标记“已出票”也可以系统自动出票。退票流程相对简单学生在“我的订单”里选择已支付且未出票的订单。系统校验订单状态、退票时间。标记订单为“已退票”同时释放对应的余票数量。如果是模拟支付退款逻辑可以只更新状态和记录金额不需要真的调用支付接口。这里要特别强调第4步“锁定余票”的概念。因为订单不是瞬间支付完成的如果不锁定余票用户A提交订单后、支付之前其他用户可能已经把最后一张票买走等A支付时就没有票了。锁定余票的常用办法是扣减余票数量并设置订单的失效时间超时未支付再恢复余票。这个机制是订票系统区别于普通CRUD项目的关键点也是答辩时最值得讲的地方。3. 技术栈选型和数据库表设计这几张表决定了系统好不好扩展3.1 技术栈选型课程设计够用但建议往主流框架靠如果只是完成课程设计用JSPServletJDBCMySQL完全够用这是老师们最熟悉的组合代码全在自己手里也能顺便练一下JDK环境变量配置和Tomcat部署。但我个人建议有条件的话尽量用Spring Boot MyBatis。理由是事务管理非常省事一个Transactional注解就能解决之前说的锁票和订单一致性内置的HikariCP连接池也避免了手写连接池的很多坑参数校验和全局异常处理都有成熟方案代码量比JSP时代少一大截。我当时选的组合是Spring Boot 2.x MyBatis MySQL 8 Thymeleaf。没有做成前后端分离因为课程设计阶段用服务端渲染更直观部署和演示都简单。如果你对前端有把握也可以拆成Vue Spring Boot接口但那样工作量会明显增加要量力而行。3.2 核心表设计这几张表缺一不可数据库设计是整个系统里我花时间最多的地方因为表结构一旦定错了后面改起来非常痛苦。我最终保留了这几张核心表student学生用户表id、username、password、real_name、id_card_no、student_no、phone、create_time。train车次表id、train_no、start_city、end_city、start_time、end_time、seat_type、price。train_stock车次余票表id、train_id、travel_date、seat_type、total_count、remain_count。orders订单表id、order_no、student_id、train_id、travel_date、seat_type、ticket_count、ticket_amount、status、create_time、pay_time、cancel_time。为什么车次表里不直接放“硬座余票”“硬卧余票”两个字段因为车次在不同日期、不同座位类型的余票是独立变化的。如果直接把余票字段写在train表里就只能用固定列增加一种座位类型就要改表结构。把余票拆到train_stock表以车次、日期、座位类型三个字段唯一确定一条库存记录系统扩展性会好很多。座位是否要细化到具体座位号是另一个需要决策的点。如果只是模拟学生订票不需要精确到座位号只需要控制总数如果想更贴近真实场景可以增加seat表记录某车次某日期的每个座位状态空闲、已占、锁定。我第一版没做座位表后来为了演示并发锁票又加了一张seat表学生订票时会选中一个具体座位并锁定。这块属于锦上添花不影响核心流程。3.3 为什么余票不要只存一个数字我见过不少同学的设计是车次表里直接放一个remain字段下单时先查这个数字如果大于0就减一。这种做法在小流量下没问题但在并发场景下会出大问题。而且余票往往要跟“日期”关联同一趟车明天的票可能还剩100张后天的票已经卖完了。如果把余票字段放在车次表里根本没法表达“某个日期有没有票”。正确的做法是把“车次”和“某天某座位类型的余票”拆成两个维度。train表描述车次本身train_stock表描述车次在某一天某种座位类型的库存。这样查询某个日期的余票就变成一次普通的联表查询扣减余票也就是对train_stock表的一行做更新。以后如果要支持更多日期、更多座位类型不需要改表结构只需要加数据行。这个设计是我觉得整个项目里最有“数据库设计感”的地方也是答辩时一定要讲清楚的点。4. 核心代码思路余票扣减、订单生成和座位锁定怎么做到不超卖4.1 订票流程的事务边界先划清楚首先明确一点提交订票产生订单和扣减余票必须发生在同一个事务里。如果先扣余票再生成订单万一生成订单失败余票就白白少了如果先生成订单再扣余票万一扣减失败就会出现有订单但没票的数据。所以这两个操作要么一起成功要么一起回滚。在Spring Boot里我直接在Service方法上加了Transactional(rollbackFor Exception.class)。这里要注意默认的rollbackFor只对运行时异常生效如果方法里catch住了异常事务不会自动回滚。要写成rollbackFor Exception.class并且不要在方法内部把异常吞掉。4.2 余票扣减用条件更新不要先查再改这是整个系统最重要的并发控制点。很多新手会这样写TrainStock stock stockMapper.selectByTrainIdAndDate(trainId, travelDate); if (stock.getRemainCount() 0) { stockMapper.decreaseRemainCount(stock.getId()); }这段代码在单线程下没问题但在并发抢票时会超卖。两个线程同时查到remainCount1都认为有票都去执行扣减最后余票变成-1但两个订单都创建成功了。这就是经典的“先查再改”的竞态条件。正确的做法是使用条件更新把判断和扣减合并成一条SQLUPDATE train_stock SET remain_count remain_count - 1 WHERE id #{stockId} AND remain_count 0;执行这条SQL后如果返回值是1说明扣减成功代表这次真的拿到了一张票如果返回值是0说明余票已经不够直接提示用户无票。整个过程不需要先查余票也不存在判断和扣减之间的时间差。这是防超卖的核心。如果还需要锁定某一行数据也可以先执行select ... for update再在Java里判断余票是否足够最后更新。但select for update会一直持有数据库行锁直到事务结束并发能力比条件更新弱一些适用于对准确性要求极高、并发量不大的场景。课程设计阶段条件更新已经足够而且代码更简洁。4.3 订单号、支付状态与超时释放订票成功后要生成订单号。订单号不要用数据库自增ID直接给用户看因为会暴露订单量而且多表关联时不够唯一。我用的方案是“时间戳 随机数”拼一个字符串保证并发下也不会重复String orderNo T System.currentTimeMillis() String.format(%04d, new Random().nextInt(10000));实际项目中会用雪花算法或Redis自增ID但课程设计用这个已经够了。订单状态我定义成整数0待支付、1已支付、2已出票、3已退票、4已取消。为什么要用枚举或常量类而不是直接写魔法数字因为代码里到处是status 1这种判断时间长了根本分不清1代表什么阅读和修改都困难。超时未支付的订单需要释放余票。我在项目里写了一个定时任务每隔一分钟扫描状态为待支付且创建时间超过15分钟的订单把它们改成已取消同时恢复对应的余票数量。这个逻辑必须在事务里执行先更新订单状态再增加余票数量顺序不能反否则一旦异常会导致两边数据不一致。4.4 防止重复提交订单订票按钮如果被用户连点两次或者前端网络重试会产生两个重复订单。前端能做的是点击后立即禁用按钮但后端也必须做幂等。我采用的简单方案是前端在提交订单时生成一个唯一的requestId后端先根据requestId查一下是否已经处理过如果处理过就直接返回上一次的订单结果。更工业级的方案是用Redis的setnx做分布式锁但课程设计里一套requestId查重表已经够了。这里要提醒一下幂等性和防并发超卖是两个不同层面的问题前者是防重复后者是防超量两者都要处理。4.5 事务异常处理别把异常吞掉写了Transactional后服务层方法内部要尽量避免catch住业务异常而不抛出。比如库存扣减失败返回0你应该throw new RuntimeException(余票不足)让事务回滚如果只是返回提示给前端而不抛出事务可能会继续执行并提交导致订单在语义上是失败的但数据却写进去了。我一开始就吃过这个亏后来养成了习惯所有可能导致事务回滚的地方一律抛出异常统一由全局异常处理器转成友好的提示信息。5. 实操中踩过的几个坑乱码、并发超卖和JDBC连接泄漏5.1 中文乱码的完整排查链路第一次跑通页面后我遇到最典型的坑是中文乱码。学生姓名、车次终点站全部显示成问号。它不是一个原因造成的而是一整条链路都要配置正确页面编码HTML文件meta指定charsetUTF-8JSP页面pageEncodingUTF-8。请求编码Servlet里request.setCharacterEncoding(UTF-8)Spring Boot里可以配置CharacterEncodingFilter。响应编码response.setContentType(text/html;charsetUTF-8)或Spring Boot的server.servlet.encoding配置。数据库连接URLjdbc:mysql://localhost:3306/train?useUnicodetruecharacterEncodingutf8。表结构和字段的collation要是utf8mb4或utf8。如果还出现乱码就用排除法先看页面源码里有没有乱码再看数据库里存的值是不是乱码逐层定位。别一上来就在代码里到处加编码设置那样越改越乱。我最后写了个过滤器统一设置请求和响应编码后来就没再碰过乱码问题。5.2 并发超卖500个人抢100张票这个坑我印象最深。第一版系统在单机测试时一切正常但当我用Jmeter模拟500个并发用户抢100张票时发现最终订单数超过100部分用户还支付成功了可余票变负数。我当时的实现就是“先查余票再更新”查出来的100和实际扣减之间隔了好几步操作高并发下必然出问题。排查过程是这样的先在订单表查总量发现超过100再查train_stock表发现remain_count变成了负数接着单独跑一个脚本模拟1000次并发扣减稳定复现。定位到是“先查再改”的并发问题后我改成了前面说的条件更新SQL再重新压测订单数量严格等于100余票为0且不为负。这件事让我意识到很多数据库层面的问题只有在高并发下才会暴露普通功能测试根本覆盖不到。5.3 JDBC连接没关导致系统假死用JSPServlet版本时我还遇到过系统跑一会儿就卡死的情况重启Tomcat又能好几分钟过一会儿又卡死。最后看控制台报错发现是获取数据库连接超时。原因是代码里执行完SQL后没有在finally块里关闭Connection连接被占用后没有归还连接池被耗尽。排查方法很简单在数据库客户端执行show processlist看连接数会发现一堆Sleep连接卡在那里。规范做法是用try-with-resources或在finally里依次关闭ResultSet、Statement、Connection而且关闭顺序要和打开顺序相反。换到Spring Boot MyBatis之后这个坑基本不会再遇到因为MyBatis帮我们管理了连接生命周期但理解这个原理还是很重要。另外我在新建项目时还遇到过两个和环境相关的问题一个是JDK版本太高老教程里的Applet类在高版本JDK中已经被移除启动时会报NoClassDefFoundError解决办法是换回JDK 8或者找到对应的替代依赖另一个是用Lombok时IDE提示当前编译器不支持Lombok多半是Lombok版本和JDK版本不匹配升级Lombok依赖版本或者检查IDE的注解处理器配置即可。这些问题跟业务代码无关纯属环境兼容但很耗时间提前知道能少走不少弯路。5.4 日期比较和SimpleDateFormat线程安全查询车次时如果按日期字符串比较比如把2025-06-01当字符串比较大多数情况下能用但格式不统一时会出问题。我在项目里统一用LocalDate来表示乘车日期数据库字段也直接用date类型避免字符串比较带来的隐晦错误。另外SimpleDateFormat不是线程安全的。如果把它定义成static字段在高并发下会偶发时间解析错乱甚至抛异常。我一开始没注意压测时出现了一些诡异的时间转换错误后来改成在方法内部创建SimpleDateFormat或者直接用DateTimeFormatter。这个知识点在很多Java面试八股文里都会考做项目时踩一次坑印象会特别深。6. 答辩和面试时怎么把这个项目讲出亮点6.1 用“用户故事”描述系统而不是背功能列表答辩时很多同学喜欢把每个功能的截图放一遍这是大忌。老师想听的是你怎么设计、怎么解决难点不是你点了几下按钮。我准备的讲法是把它当成一个完整的用户故事来讲。比如“一个学生小张想买后天从北京到上海的车票他打开系统输入出发地、目的地和日期系统返回两趟可选车次。他选择其中一趟提交订单此时系统会锁定一张票预留15分钟让他模拟支付。支付成功后订单生成出票完成。如果小张不支付15分钟后系统自动取消订单并释放余票。”讲清楚这条主线再引出你为支撑这条主线做了哪些设计整体逻辑就非常清晰。6.2 三句话讲清楚技术亮点如果把项目概括成三个技术亮点我会这么说第一扣减余票使用了条件更新SQL把“判断余票是否充足”和“扣减余票”合并成原子操作防止并发超卖。第二订票和扣库存放在同一个事务里任何一步失败都会整体回滚保证数据一致。第三整个项目采用分层架构Controller、Service、Mapper职责分离异常通过全局处理器统一转换。这三句话听起来简单但每一句背后都有代码支撑面试官顺着问下去你能答出来的内容就是你和其他候选人的区别。6.3 把八股文知识点落到项目里准备Java面试时很多人会背八股文但一到项目描述就不知道怎么说。其实这个项目能挂靠的知识点非常多Java集合车次查询结果如何用List和Map组合缓存座位类型如何用Map组织。多线程用线程池模拟并发抢票观察超卖问题。异常处理全局异常处理和事务回滚。反射与动态代理Spring Boot框架里大量使用项目启动时Controller如何被注册。数据库事务隔离级别为什么默认的RR级别下悲观锁能生效。面试时被问到“你的项目里遇到过什么并发问题”就把5.2节的压测复现和修复过程讲出来被问到“事务怎么保证一致性”就把4.1节和4.5节的异常回滚讲出来。用自己的代码讲故事比背定义有说服力得多。6.4 后续扩展方向如果时间和精力允许这个项目还可以往三个方向扩展一是用Redis缓存热点车次的余票查询时直接读缓存订票时用Redis的increment原子操作扣减再去异步同步数据库。这里要注意RedisTemplate的increment方法返回的是Long配置序列化器时别把类型搞混否则会报类型转换或序列化异常。二是引入消息队列做异步出票。订票成功后先返回“处理中”订单状态到了消息队列再异步完成真正出票这样系统在高并发下的响应速度会更快。三是改造成前后端分离架构后端只提供REST接口前端用Vue或小程序实现。这个方向更贴近真实企业项目如果打算找Java开发岗建议至少把接口写规范包括统一返回体、统一异常结构、参数校验注解。最后再分享一点个人体会做完这个项目我最深的感受是“业务逻辑比技术框架更值得花时间”。框架选型可以换但订票流程中的锁票、余票、超时释放这些业务点无论换成什么技术栈都要面对。你把这个系统的业务规则梳理得越清楚代码写起来越顺手后面面试讲起来也越自信。如果你正在准备课程设计或练手项目这个题目真的值得认真做一遍尤其是把并发扣减和事务边界想明白收获会远超预期。本文还有配套的精品资源点击获取