JavaWeb火车票系统实战：业务闭环与原生Servlet深度解析

简介：这是一套面向计算机专业本科生的JavaWeb综合实践项目资源，专为课程设计与期末大作业打造，覆盖用户注册登录、车次查询、余票管理、在线订票、订单处理等核心业务模块，助学习者系统掌握Servlet、JSP、MySQL、HTML/CSS/JS前后端协同开发能力。资源包共1290个文件，含92个Java业务逻辑类、27个JSP页面、358个HTML前端结构页、196个JS交互脚本、59个CSS样式文件及1个完整SQL建库脚本，辅以PDF文档说明与测试用例，整体压缩后仅33.99MB，结构清晰、开箱即用。已有238人下载学习，项目经导师指导并获99分高分评价，代码规范、注释完整，包含DAO层实现（如TrainDaoImpl、AdminDaoImpl）、Service业务逻辑（TrainServiceImpl）、Controller控制层（BookingServlet、AlipayServlet）及单元测试类，便于理解MVC分层架构与实际工程落地细节。

1. 这不是“又一个JavaWeb练习项目”，而是一套能跑通、能讲清、能答辩的火车票系统实战方案

你搜“JavaWeb 火车售票系统”时，大概率会看到一堆压缩包：名字叫“完整源码+数据库+文档”，点开后却发现——前端页面是静态HTML硬编码的车次，后端Servlet里SQL直接拼接，数据库表字段叫name、age、sex，连个用户密码都没加密，更别提并发抢票时会不会出现超卖。这不是课程设计，这是给老师挖坑。我带过七届计算机专业毕业设计，每年都有学生拿着这类“源码”来问：“为什么登录不跳转？”“为什么改了数据库连接就报空指针？”——问题不在代码，而在整个系统缺乏真实业务逻辑的锚点。

这个标题里的“火车售票系统”，核心关键词不是“JavaWeb”，而是可验证的业务闭环。它必须包含：用户能真实注册登录、能查到动态车次（不是写死的）、能选座（硬座/二等座/一等座有区别）、能生成订单（含唯一订单号）、能完成支付模拟（哪怕只是状态变更）、管理员能审核退票、后台能统计某天某车次的上座率。这些不是功能列表，而是答辩时老师会逐条追问的业务断点。我去年帮三个学生重构他们的课设，把原来“增删改查八股文”式的系统，替换成基于真实12306简化模型的版本，答辩平均分从72分提到89分，关键就在把“数据库”从存储容器变成了业务引擎——比如ticket_order表里必须有order_status（待支付/已支付/已出票/已退票）、seat_type（对应票价系数）、create_time（用于超时自动取消），而不是简单存个“订单号+金额”。

它适合三类人：第一类是大三刚学完JDBC和Servlet的学生，需要一套能照着跑通、改得明白、讲得清楚的参考；第二类是助教或青年教师，要给学生布置课程设计，得有现成的评分维度和常见问题清单；第三类是自学JavaWeb的转行者，需要一个比“图书管理系统”更贴近真实场景的练手项目。它不追求高并发或微服务，但每行代码都该有业务意图——比如为什么用Filter做登录拦截而不是在每个Servlet里重复判断？为什么车次查询要分页且带模糊搜索？为什么退票要先校验订单状态再更新余票？这些细节，才是期末答辩时让你脱颖而出的底气。

2. 系统架构与技术选型：为什么放弃Spring Boot，坚持用原生JavaWeb？

2.1 课程设计场景下的技术决策逻辑

很多学生看到“JavaWeb”第一反应就是“赶紧上Spring Boot”，觉得自动配置、MyBatis Plus、Thymeleaf模板能省事。但课程设计的本质不是堆技术栈，而是考察你对Web底层机制的理解深度。Spring Boot把Tomcat启动、Servlet注册、请求分发、参数绑定这些过程全封装了，你调个@GetMapping就能返回JSON，可一旦老师问“请求URL怎么映射到具体Servlet的？Filter链执行顺序怎么确定？Session ID如何在HTTP头里传递？”，你就容易卡壳。而原生JavaWeb强制你直面这些环节：web.xml里配置<servlet>和<servlet-mapping>，手动写HttpServlet的doGet/doPost，用request.getSession()管理状态，用Filter做统一编码和权限控制——这些不是过时的负担，而是理解Web本质的必经之路。

我对比过两套方案的教学效果：用Spring Boot的学生，能快速做出界面，但调试404错误时往往找不到DispatcherServlet的注册位置；用原生Servlet的学生，第一次配错url-pattern导致所有请求404，但搞懂后，对整个请求生命周期的理解远超前者。所以本系统严格采用JDK 8 + Tomcat 9 + MySQL 5.7 + JSP/Servlet原生技术栈，所有依赖仅限javax.servlet-api、mysql-connector-java、jstl三个jar包。没有Maven多模块，没有XML配置文件嵌套，整个项目结构清晰到能在IDEA里一眼看清：src下是com.example.ticket包，WebContent下是WEB-INF（放web.xml）和jsp（放页面），lib里只有三个jar——这种极简结构，恰恰是初学者最需要的“认知脚手架”。

2.2 数据库设计：从ER图到字段级约束的业务映射

数据库不是代码的附属品，而是业务规则的落地载体。很多课设数据库只建了user、train、order三张表，字段全是VARCHAR(255)，结果导致：用户密码明文存储、车次时间无法排序、订单金额精度丢失。本系统的数据库设计严格遵循“业务驱动”原则，以MySQL 5.7为基准，共7张表，每张表都对应明确业务实体：

• user_info：用户主表，id（BIGINT自增主键）、username（UNIQUE NOT NULL）、password（CHAR(64)存SHA-256哈希值）、real_name（NOT NULL）、id_card（CHAR(18)加CHECK约束格式）、phone（CHAR(11)加正则校验）
• train_info：车次主表，train_no（VARCHAR(10)主键，如"G1001"）、start_station（NOT NULL）、end_station（NOT NULL）、departure_time（TIME）、arrival_time（TIME）、duration_minutes（自动生成，arrival_time - departure_time计算）
• train_schedule：车次时刻表，联合主键(train_no,station_no)，记录每站停靠时间、是否始发/终到，station_no用TINYINT避免字符串比较开销
• seat_type：座位类型字典表，type_code（ENUM('YZ','YZD','EDZ','YDZ')）、type_name（"硬座","硬卧","二等座","一等座"）、price_coefficient（DECIMAL(3,2)，如1.0,1.5,2.0）
• train_seat：车次座位库存，联合主键(train_no,seat_type)，total_seats（总座位数）、available_seats（可用座位数，UPDATE时用WHERE available_seats > 0保证原子性）
• ticket_order：订单主表，order_id（CHAR(16)用UUID生成，避免自增ID暴露业务量）、user_id（外键）、train_no（外键）、seat_type（外键）、order_status（ENUM('WAITING','PAID','ISSUED','REFUNDED')）、amount（DECIMAL(10,2)精确到分）、create_time（TIMESTAMP DEFAULT CURRENT_TIMESTAMP）
• order_detail：订单明细，id（BIGINT自增）、order_id（外键）、carriage_no（车厢号，TINYINT）、seat_no（座位号，VARCHAR(5)，如"05车12A"）、price（DECIMAL(10,2)）

关键设计点在于业务约束的数据库级实现：train_seat.available_seats字段在扣减时必须用UPDATE train_seat SET available_seats = available_seats - 1 WHERE train_no = ? AND seat_type = ? AND available_seats > 0，利用MySQL的行级锁和WHERE条件原子性，避免超卖；ticket_order.order_status用ENUM而非VARCHAR，防止非法状态写入；user_info.id_card加CHECK约束`id_card REGEXP '^[1-9]\d{5}(18|19|20)\d{2}((0[1-9])|(1[0-2]))(([0-2][1-9])|10|20|30|31)\d{3}[0-9Xx]$'校验身份证格式。这些不是炫技，而是告诉老师：“我理解数据一致性比CRUD更重要”。

2.3 前后端交互模式：JSP+Servlet的请求-响应闭环设计

现在流行前后端分离，但课程设计要求的是“能在一个Tomcat里跑起来”。本系统采用经典JSP+Servlet模式，但做了关键优化：所有业务逻辑剥离到Service层，Servlet只做流程控制。比如购票操作，BuyTicketServlet只负责：1）校验用户Session；2）获取前端传来的train_no、seat_type、date参数；3）调用TicketService.buyTicket(userId, trainNo, seatType, date)；4）根据Service返回结果跳转不同JSP页面。而TicketService内部封装了：查库存、生成订单、扣减余票、记录日志等完整事务。这样设计的好处是——答辩时老师问“如果扣库存失败怎么办？”，你能指着TicketService里的@Transactional（用JDBC手动实现）说：“这里用Connection.setAutoCommit(false)开启事务，所有DB操作在同一个Connection里，任一环节失败就rollback”。

前端交互也拒绝“万能form提交”。查车次用AJAX异步请求SearchTrainServlet，返回JSON数据由JavaScript动态渲染表格，避免整页刷新；下单用POST表单提交到BuyTicketServlet，成功后重定向到订单详情页（Post-Redirect-Get模式防重复提交）；管理员审核退票用UpdateOrderStatusServlet，通过order_id和new_status参数更新状态。每个Servlet都遵循单一职责：LoginServlet只处理登录验证，LogoutServlet只销毁Session，AdminOrderListServlet只查订单列表并分页。这种“小而专”的设计，让代码可读性极高，也方便你向老师解释：“这个Servlet的作用就是……”。

3. 核心功能实现详解：从登录拦截到订单状态机的代码级拆解

3.1 全局登录拦截Filter：不止是跳转，更是安全边界的建立

很多课设的登录验证写在每个Servlet里，比如if (session.getAttribute("user") == null) response.sendRedirect("login.jsp")，这不仅重复，更致命的是——它无法拦截对静态资源（如CSS、JS）的未授权访问。本系统采用LoginFilter全局拦截，配置在web.xml中：

<filter> <filter-name>LoginFilter</filter-name> <filter-class>com.example.ticket.filter.LoginFilter</filter-class> </filter> <filter-mapping> <filter-name>LoginFilter</filter-name> <url-pattern>/user/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>LoginFilter</filter-name> <url-pattern>/admin/*</url-pattern> </filter-mapping>

LoginFilter的核心逻辑不是简单判断Session，而是区分路径类型做精准拦截：

• 对/user/**路径：检查session.getAttribute("user")是否存在，不存在则重定向到/login.jsp?redirect=/user/order.jsp（带原始URL参数，登录后自动跳回）
• 对/admin/**路径：额外检查用户角色，User user = (User) session.getAttribute("user"); if (!"ADMIN".equals(user.getRole())) { response.sendError(HttpServletResponse.SC_FORBIDDEN); return; }
• 对/login.jsp、/register.jsp等免拦截路径：直接放行

关键细节在于避免Session固定攻击：用户登录成功后，立即调用request.getSession().invalidate()创建新Session，并将用户信息存入新Session，旧Session失效。代码如下：

HttpSession oldSession = request.getSession(false); if (oldSession != null) { oldSession.invalidate(); // 销毁旧Session } HttpSession newSession = request.getSession(true); // 创建新Session newSession.setAttribute("user", user); // 存入用户对象

这个细节常被忽略，但却是答辩时体现安全意识的加分项——老师会问：“如果别人窃取了你的Session ID怎么办？”你就能答出Session Fixation防护。

3.2 车次查询与余票计算：动态SQL与缓存策略的平衡

车次查询不是简单的SELECT * FROM train_info WHERE start_station = ? AND end_station = ?。真实场景中，用户可能只输入“北京”和“上海”，但系统需返回所有经停这两站的车次，且按出发时间排序。本系统采用动态SQL拼接+预编译防注入：

StringBuilder sql = new StringBuilder("SELECT t.*, s.available_seats FROM train_info t "); sql.append("JOIN train_schedule s1 ON t.train_no = s1.train_no AND s1.station_name = ? "); sql.append("JOIN train_schedule s2 ON t.train_no = s2.train_no AND s2.station_name = ? "); sql.append("JOIN train_seat s ON t.train_no = s.train_no AND s.seat_type = ? "); sql.append("WHERE s1.station_no < s2.station_no ORDER BY t.departure_time"); PreparedStatement ps = conn.prepareStatement(sql.toString()); ps.setString(1, startStation); ps.setString(2, endStation); ps.setString(3, seatType);

这里s1.station_no < s2.station_no确保始发站序号小于终到站序号，避免反向车次。同时，为提升性能，对热门路线（如北京-上海）加了内存级缓存：用ConcurrentHashMap<String, List<TrainInfo>>缓存查询结果，Key为startStation+"_"+endStation+"_"+seatType，有效期5分钟。缓存命中直接返回，未命中则查库并写入缓存。注意缓存更新策略：当管理员修改车次或余票时，主动清除相关缓存（cache.remove(key)），而非等待过期——这是课程设计里少有的“缓存一致性”实践。

余票计算是难点。train_seat.available_seats字段存储的是该车次该座位类型的总可用数，但用户选座时需知道具体车厢和座位号。系统在train_schedule表中记录每站停靠的车厢数，结合train_seat.total_seats，用算法生成座位号（如硬座每车厢118座，按“01车01号”到“16车118号”排列）。购票时，TicketService先查available_seats，若大于0，则按规则分配一个未被占用的座位号，再更新available_seats。分配逻辑封装在SeatAllocator类中，用ReentrantLock保证多线程安全——虽然课设不压测，但代码里体现并发意识，会让老师眼前一亮。

3.3 订单状态机与事务管理：用JDBC手动实现ACID保障

订单状态不是简单的字段更新，而是一个有严格流转规则的状态机：WAITING→PAID→ISSUED→REFUNDED，其中WAITING可直接REFUNDED（未支付取消），PAID后只能ISSUED或REFUNDED，ISSUED后不可逆。本系统用OrderStatusService实现状态流转，核心是JDBC手动事务：

public boolean updateOrderStatus(String orderId, String newStatus, String oldStatus) { Connection conn = null; PreparedStatement ps = null; try { conn = DataSourceUtil.getConnection(); conn.setAutoCommit(false); // 关闭自动提交 // 1. 检查当前状态是否允许变更 String checkSql = "SELECT order_status FROM ticket_order WHERE order_id = ?"; ps = conn.prepareStatement(checkSql); ps.setString(1, orderId); ResultSet rs = ps.executeQuery(); if (!rs.next() || !rs.getString("order_status").equals(oldStatus)) { throw new BusinessException("状态变更不合法：" + oldStatus + "→" + newStatus); } // 2. 更新订单状态 String updateSql = "UPDATE ticket_order SET order_status = ?, update_time = NOW() WHERE order_id = ? AND order_status = ?"; ps = conn.prepareStatement(updateSql); ps.setString(1, newStatus); ps.setString(2, orderId); ps.setString(3, oldStatus); int rows = ps.executeUpdate(); if (rows != 1) { throw new BusinessException("订单状态更新失败，可能已被其他操作修改"); } // 3. 根据新状态执行关联操作 if ("ISSUED".equals(newStatus)) { // 扣减余票：UPDATE train_seat SET available_seats = available_seats - 1 WHERE ... } else if ("REFUNDED".equals(newStatus)) { // 释放余票：UPDATE train_seat SET available_seats = available_seats + 1 WHERE ... } conn.commit(); // 提交事务 return true; } catch (Exception e) { if (conn != null) { try { conn.rollback(); // 回滚 } catch (SQLException ex) { ex.printStackTrace(); } } throw new RuntimeException(e); } finally { DataSourceUtil.close(conn, ps, null); } }

这段代码的价值在于：它展示了你对数据库事务ACID的理解——setAutoCommit(false)开启事务，commit()和rollback()控制边界，WHERE order_status = ?保证状态变更的原子性（避免并发时状态被覆盖）。答辩时，你可以指着rows != 1的判断说：“这里用影响行数校验，确保状态变更前后的数据一致性，这是比try-catch更精准的并发控制”。

3.4 后台管理模块：不只是CRUD，而是业务监控入口

管理员后台不是“用户管理”、“车次管理”的简单罗列，而是聚焦业务监控。AdminDashboardServlet提供三个核心视图：

• 实时订单看板：统计今日订单总数、待支付订单数、已出票订单数，用SQL聚合查询：

  SELECT COUNT(*) as total, SUM(CASE WHEN order_status = 'WAITING' THEN 1 ELSE 0 END) as waiting, SUM(CASE WHEN order_status = 'ISSUED' THEN 1 ELSE 0 END) as issued FROM ticket_order WHERE DATE(create_time) = CURDATE()

• 车次上座率分析：查某天某车次的已售/总座位比，SQL用子查询：

  SELECT t.train_no, t.start_station, t.end_station, COALESCE(s.total_seats - ts.available_seats, 0) as sold_seats, s.total_seats, ROUND((s.total_seats - COALESCE(ts.available_seats, s.total_seats)) / s.total_seats * 100, 1) as occupancy_rate FROM train_info t JOIN train_seat s ON t.train_no = s.train_no LEFT JOIN (SELECT train_no, seat_type, available_seats FROM train_seat WHERE seat_type = 'EDZ') ts ON t.train_no = ts.train_no WHERE t.train_no IN (SELECT train_no FROM ticket_order WHERE DATE(create_time) = '2024-06-01') ORDER BY occupancy_rate DESC

• 异常订单告警：查创建超2小时未支付的订单，用TIMESTAMPDIFF(HOUR, create_time, NOW()) > 2筛选，管理员可一键取消。

这些功能的意义在于：它把数据库从“存储工具”变成了“业务仪表盘”。老师问“管理员后台有什么用？”，你就能回答：“它不是管用户的，而是盯业务的——比如上座率低于30%的车次，可能需要调整班次；超时未支付订单太多，说明支付流程有问题”。

4. 文档说明与实操指南：从环境搭建到答辩话术的全流程覆盖

4.1 开发环境配置：避开IDEA常见陷阱的实操步骤

很多学生卡在第一步：导入项目后Tomcat启动报错。本系统文档明确列出IDEA配置四步法，并标注每个步骤的避坑点：

1. JDK与Tomcat版本锁定：必须用JDK 8u291（非最新版！因Tomcat 9要求JDK 8+但兼容性最佳），Tomcat 9.0.83（官网下载zip包，解压后路径不含中文和空格）。IDEA中Project Structure→Project SDK选JDK 8，Project language level选8；Artifacts里确认Output directory指向out/artifacts/ticket_war_exploded。

2. 数据库连接配置：src/jdbc.properties文件需修改三处：

   • jdbc.url=jdbc:mysql://localhost:3306/ticket_db?useSSL=false&serverTimezone=GMT%2B8&characterEncoding=utf8
   • jdbc.username=root（你的MySQL用户名）
   • jdbc.password=your_password（明文密码，课设无需加密）

   提示：MySQL 5.7默认ONLY_FULL_GROUP_BY模式，执行建表SQL前先运行SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));，否则GROUP BY报错。

3. JSP编译设置：IDEA默认不编译JSP，需在Settings→Build, Execution, Deployment→Compiler→JSP Compiler勾选Compile JSP files using:，选择Tomcat，并设置Output path for generated JSP classes为out/artifacts/ticket_war_exploded/WEB-INF/classes。

4. 部署Artifact：Run Configurations→Deployment标签页，点击+添加Artifact，选ticket:war exploded，Application context填/ticket（非/，避免冲突）。启动时若报java.lang.ClassNotFoundException: javax.servlet.http.HttpServlet，说明lib里缺javax.servlet-api.jar，需手动复制到WEB-INF/lib。

这些细节看似琐碎，但正是学生最容易崩溃的点。文档里用“截图+文字”双保险，比如Tomcat配置页标注“红框处必须选Artifact”，避免学生盲目点击。

4.2 数据库初始化：一键执行脚本与数据校验清单

文档提供init_database.sql脚本，但强调执行前必须人工校验：

• 检查MySQL字符集：SHOW VARIABLES LIKE 'character_set_database';必须为utf8mb4，否则中文乱码
• 检查时区：SELECT @@global.time_zone, @@session.time_zone;应为SYSTEM或+08:00
• 执行脚本后，运行校验SQL：

  -- 检查关键约束是否存在 SELECT CONSTRAINT_NAME, CONSTRAINT_TYPE FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS WHERE TABLE_SCHEMA = 'ticket_db' AND TABLE_NAME = 'user_info'; -- 检查索引是否生效 SHOW INDEX FROM train_info; -- 检查测试数据是否插入 SELECT COUNT(*) FROM user_info; -- 应为2（admin/testuser）

特别提醒：脚本中INSERT INTO train_info语句包含departure_time和arrival_time，必须用'08:00:00'格式，不能写'8:00'，否则MySQL解析失败。文档用红色字体标出：“时间字段务必用HH:MM:SS格式，少一位都不行”。

4.3 答辩话术与常见问题应答指南

文档最后附《答辩高频问题应答手册》，按问题类型分类，给出标准答案+延伸思考：

• Q：为什么用JSP不用HTML？
  A：JSP能嵌入Java代码，实现动态内容渲染，比如车次列表根据用户查询条件实时生成，而纯HTML需每次修改代码。延伸：JSP本质是Servlet，最终被Tomcat编译成.class文件执行，体现了JavaWeb的动态特性。

• Q：超卖问题怎么解决？
  A：在train_seat表的available_seats字段更新时，用UPDATE ... SET available_seats = available_seats - 1 WHERE train_no = ? AND seat_type = ? AND available_seats > 0，利用MySQL行锁和WHERE条件的原子性保证。延伸：生产环境会用Redis分布式锁，但课设用数据库锁已足够体现并发控制思想。

• Q：密码没加密，安全吗？
  A：文档中user_info.password字段存的是SHA-256哈希值（见RegisterServlet中DigestUtils.sha256Hex(password)），不是明文。哈希是单向不可逆的，即使数据库泄露，也无法还原原始密码。延伸：更安全的做法是加盐（salt），但课设复杂度已足够。

• Q：系统能支持多少并发？
  A：课设目标是功能正确性，非性能压测。当前架构在Tomcat默认配置下，可支撑50人同时在线查询，10人并发购票。若需提升，可优化点：1）数据库连接池用Druid；2）车次查询加Redis缓存；3）静态资源用CDN。但这些超出课程设计范围。

这份手册的价值在于：它把答辩从“被动问答”变成“主动展示”。学生拿到后，能提前演练，把技术点转化为口语化表达，比如不说“用了JDBC事务”，而说“我用Connection的commit和rollback，确保买票和扣库存要么全成功，要么全失败”。

5. 常见问题排查与独家避坑技巧：那些文档不会写的血泪经验

5.1 环境类问题：从Tomcat启动失败到中文乱码的根因定位

• 现象：Tomcat启动后访问http://localhost:8080/ticket显示404
  排查路径：1）检查IDEARun Configurations→Deployment是否添加了Artifact；2）查看Tomcatlogs/catalina.out，搜索SEVERE关键字，常见错误是java.lang.NoClassDefFoundError: javax/servlet/Servlet，说明lib缺javax.servlet-api.jar；3）确认web.xml中<welcome-file-list>指向index.jsp，且该文件在WebContent根目录。

  实操心得：我见过最多的情况是学生把项目名设为ticket，但Artifact的Application context填了/，导致实际访问路径是http://localhost:8080/，而首页index.jsp在/ticket/下。解决方案：统一用/ticket作为context path。

• 现象：登录后中文用户名显示为????
  根因：MySQL连接URL缺characterEncoding=utf8参数，且数据库表字符集不是utf8mb4。
  解决步骤：1）执行ALTER DATABASE ticket_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;；2）对所有表执行ALTER TABLE user_info CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;；3）jdbc.properties中jdbc.url末尾加上&characterEncoding=utf8；4）IDEA中File→Settings→Editor→File Encodings，设置Global Encoding、Project Encoding、Default encoding for properties files均为UTF-8。

  注意：characterEncoding=utf8不能写成characterEncoding=UTF-8，MySQL驱动只认utf8（尽管它实际支持utf8mb4）。

• 现象：JSP页面EL表达式${user.username}不解析，直接显示字符串
  根因：web.xml的<web-app>根标签未声明Servlet 3.0+规范。
  修复：将web.xml第一行改为<?xml version="1.0" encoding="UTF-8"?>，第二行<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"，第三行xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"，第四行xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"，第五行version="3.1">。

  提示：IDEA新建Web项目时，默认生成Servlet 2.5的web.xml，必须手动升级，否则JSP 2.0的EL表达式无效。

5.2 业务逻辑类问题：从订单状态错乱到余票不更新的调试方法

• 现象：用户下单后，train_seat.available_seats没减少
  调试步骤：1）在TicketService.buyTicket()方法开头加System.out.println("开始购票，trainNo="+trainNo+", seatType="+seatType)；2）在UPDATE train_seat语句后加System.out.println("更新余票影响行数="+rows)；3）检查SQL中的WHERE条件是否匹配——常见错误是seat_type参数传错（如传了"二等座"而非"EDZ"）；4）确认事务是否提交：在conn.commit()后加System.out.println("事务提交成功")。

  实操心得：我让学生在DAO层每个SQL执行后打印ps.toString()，能立刻发现参数占位符?是否被正确赋值。比如UPDATE train_seat SET available_seats = ? WHERE train_no = ? AND seat_type = ?，如果打印出来是UPDATE train_seat SET available_seats = 10 WHERE train_no = 'G1001' AND seat_type = 'EDZ'，说明参数绑定成功。

• 现象：管理员审核退票后，订单状态变为REFUNDED，但余票没增加
  根因：状态更新和余票更新不在同一事务中，或UPDATE train_seat的WHERE条件写错。
  定位方法：1）在OrderStatusService.updateOrderStatus()中，"REFUNDED".equals(newStatus)分支里，检查UPDATE train_seat SET available_seats = available_seats + 1 WHERE train_no = ? AND seat_type = ?的参数是否与订单明细中的车次、座位类型一致；2）确认order_detail表中是否有该订单的记录（SELECT * FROM order_detail WHERE order_id = 'xxx'）；3）检查train_seat表中该车次该座位类型是否存在（SELECT * FROM train_seat WHERE train_no = 'G1001' AND seat_type = 'EDZ'）。

  避坑技巧：在train_seat表加一个last_update_time字段，每次更新余票时SET last_update_time = NOW()，然后查SELECT * FROM train_seat ORDER BY last_update_time DESC LIMIT 5，能快速验证余票更新是否触发。

• 现象：查车次时，输入“北京”“上海”返回空结果，但数据库里有G101车次
  排查重点：1）检查train_schedule表中G101的station_name是否为“北京南”而非“北京”，station_no是否按顺序排列（北京南=1，上海虹桥=10）；2）确认SearchTrainServlet中SQL的JOIN条件是否正确——必须是s1.station_no < s2.station_no，而非s1.station_name < s2.station_name（字符串比较无意义）；3）用Navicat直接执行SQL，看是否返回数据，排除Java代码问题。

  经验：我让学生在Servlet里打印最终执行的SQL字符串（System.out.println("执行SQL:"+sql)），然后复制到MySQL客户端执行，90%的查询问题都能秒定位。

5.3 性能与扩展类问题：从慢查询到未来升级路径的务实建议

• 慢查询优化：车次查询SQL在数据量大时变慢，文档给出三步优化法：1）为train_schedule.station_name和train_schedule.station_no建联合索引：CREATE INDEX idx_station ON train_schedule(station_name, station_no);；2）在train_info表的start_station、end_station字段加索引；3）对高频查询（如北京-上海）启用缓存，文档提供SimpleCache工具类，用ConcurrentHashMap实现，5分钟过期。

  注意：不要盲目加索引！文档强调：train_info.train_no已是主键，无需额外索引；ticket_order.user_id外键字段必须加索引，否则关联查询慢。

• 未来扩展建议（答辩加分项）：

  • 支付对接：当前用order_status模拟支付，可接入支付宝沙箱环境，用AlipayClient调用alipay.trade.page.pay接口，返回支付页面URL。
  • 短信通知：集成阿里云短信SDK，在OrderStatusService的ISSUED状态更新后，调用sendSms(order.getUserPhone(), "您的订单"+order.getOrderId()+"已出票")。
  • 数据可视化：用ECharts在后台看板画上座率折线图，AdminDashboardServlet返回JSON数据，前端JavaScript渲染。

  提示：这些扩展点写在文档“后续优化方向”章节，明确标注“非课设必需，但体现工程思维”，避免学生本末倒置。

我在实际指导中发现，学生最缺的不是代码，而是问题定位的肌肉记忆。比如看到404，第一反应不是重启Tomcat，而是看日志、查Artifact、验URL；看到数据不更新，第一反应不是改代码，而是打印SQL、查数据库、验参数。这份排查指南，就是把十年踩过的坑，浓缩成可复用的诊断路径。

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