简介一套民航订票管理系统完整项目资料面向课程设计、毕业设计及桌面应用开发初学者。系统覆盖航班信息查询、客户订票退票、航班与航线管理、航班延误处理、已订票客户和会员信息管理等业务模块采用Java Swing构建图形界面配合JDBC访问SQL Server数据库可在Eclipse或IntelliJ IDEA中直接运行调试。压缩包内含118个文件以Java源码、编译生成的class字节码、XML配置、SQL数据库脚本和docx设计文档为主体另有项目配置与说明等辅助文件整体大小2.29MB结构紧凑便于学习。项目内类与方法命名规范模块边界清楚便于二次开发与功能扩展。资料中的源码与文档贴近实际课程设计场景能帮助读者理解Swing界面编程、JDBC数据操作及分层设计思路也可作为同类订票系统的开发参考或答辩素材。目前已有1816人学习下载对快速上手Java数据库应用开发很有帮助。1. 民航订票管理系统拿到手这个 zip 里真正值得花时间的东西课程设计和毕设季民航订票管理系统设计文档这类 Java 压缩包满天飞。我在帮人改这类源码的时候发现一个规律九成的人卡住不是因为代码跑不起来而是不知道该先看文档还是先跑代码。这份资源的核心价值其实不是某段精妙的代码而是「设计文档 实现源码」能对上——需求分析里写的订票流程在数据库表里能找到字段在 DAO 里能找到对应的 SQL。适合三类人拿它做课程设计交作业的在校生、需要快速搭一个 Java Web 课设 Demo 的从业者以及想搞懂「一个业务系统从文档到代码怎么落地」的初学者。这篇文章按我拆项目的习惯把解压、建库、部署、验证的顺序和每个环节的坑一次讲完。2. 设计文档先行先读懂业务边界再决定改哪里2.1 文档包的常规布局需求、设计、答辩三类文件怎么分工这类资源包解压之后常见会有一份「设计文档」或「课程设计报告」目录里面通常包含三类文件需求分析、数据库设计、详细设计。很多人习惯跳过文档直接开 IDEA结果是代码启动失败后回头翻文档翻半天找不到对应知识点。我的习惯是倒过来先用 20 分钟把文档目录扫一遍确认三件事。第一需求分析里的角色和业务流程。民航订票系统最常见的是三种角色游客、注册用户、管理员或后台管理员。游客能查航班但不能下单注册用户可以订票、取消订单管理员维护航班和舱位信息。文档里只要把这三类角色的用例和操作边界写清楚了你就能判断源码里该有哪几个控制器Controller 或 Servlet。第二数据库设计里的 E-R 图和表结构清单。这一部分直接决定了你在 MySQL 里要建几张表、表之间怎么关联。常见的民航订票系统是六到八张表核心是用户表、航班表、订单表往外延伸有乘机人表、舱位表、机场表、退票或改签记录表。读表结构的时候重点看主外键和唯一约束这比看字段列表更省时间。第三详细设计里的分层结构和接口说明。Java Web 课设哪怕不用 Spring也基本会走 Servlet JSP JDBC 或 DAO 模式。文档里如果有类图和时序图直接照图去源码里找对应类比逐个文件打开快得多。如果文档不全就用「一条订票链路」去反推系统分层这个我放在 2.3 节详细说。提示拿到资源先花十几分钟确认文档版本和代码版本一致。有的压缩包文档更新过但代码没同步导致表名字段对不上这种不匹配浪费的时间比排错还多。2.2 核心表结构拆解一条业务线写到 t_flight / t_order 里的关键字段民航订票系统的数据模型本质上是「航班余票」和「订单状态」两个维度的建模。文档里如果只有一张 E-R 图你可以自己补一张字段清单因为后面写代码、连数据库、跑 SQL 全靠它。先看航班表通常叫 t_flight 或 flight 表字段大体包括字段名类型建议作用flight_idint 或 varchar主键航班内部 IDflight_novarchar航班号如 CA1801对外展示用dep_city / arr_cityvarchar起降城市查询的核心过滤条件dep_time / arr_timedatetime起降时间一般 dep_time 建索引cabin 或 seat_typevarchar/int舱位等级如经济舱、头等舱ticket_pricedecimal票价注意用 decimal 不用 floattotal_seatsint该航班该舱位总座位数remaining_seatsint余票数订票扣减的关键字段这里最容易踩坑的是 total_seats 和 remaining_seats 分开存。有些人省事只在订单表里统计数量最后发现余票算不准还要 JOIN 订单表去做减法并发一高就会出现负数。文档里只要有这两个字段后面订票逻辑就可以用条件更新一行 SQL 搞定这个我在第 3 章详细写。再看订单表常见命名 t_order字段名类型建议作用order_idint 自增主键order_novarchar订单号对外展示一般要加唯一索引user_idint下单用户外键关联用户表flight_idint关联航班表statustinyint订单状态0 未支付 / 1 已出票 / 2 已取消 / 3 已退票create_timedatetime下单时间pay_timedatetime支付时间允许为空订单号加唯一索引这一点很多课设源码里没有。没有唯一索引理论上同一毫秒生成相同订单号插入时不会有任何报错排查问题时无从下手。文档如果没提建议自己在建表脚本里补上。民航订票和普通电商订单类似status 字段是最容易被写死的——有人用 0/1 判断有人用 payed/canceled 字符串哪种都行但必须在文档里写清楚约定。2.3 从 E-R 图到代码包用「一条订票链路」定位三层代码拿到源码包之后建议第一步不要按目录从上往下读而是选一条最核心的业务链路——订票链路用户登录、查航班、下单、扣余票、生成订单。沿着这条链路在源码里走一遍整个项目的分层就全清楚了。最典型的 Java Web 三层结构是这样对应的表现层JSP 页面 Servlet或 Controller。对应源码里的views目录和servlet/controller包。登录、查询表单在这里提交跳转逻辑由这里接管。业务层Service 类。对应订票流程里的「校验用户、校验航班、调用 DAO 扣减余票、插入订单」这一串动作。源码里如果直接由 Servlet 调 DAO 而没有 Service 层说明项目可能偏简单。数据层DAOData Access Object。对应每个数据库操作比如FlightDao、OrderDao、UserDao。DAO 里放的是 JDBC 或 DBUtils 的 SQL 执行代码。我一般会先在源码里搜两个关键词Connection和PreparedStatement。如果能在同一个包下看到这些类说明就是经典的 JDBC 直连方案如果看到druid或c3p0配置说明用了连接池。这两种方案的配置入口不一样运行时的错误特征也不一样后面部署章节会区分讲。搜完之后再看web.xml或webapp目录确认 Servlet 映射的 URL 规则比如/login、/searchFlight、/bookTicket分别对应哪个类。这一步做完你基本就知道改哪个文件能影响哪段业务而不是靠猜。3. 订票逻辑实现航班查询、余票扣减与订单状态流转3.1 航班查询模糊匹配与出行日期的 JDBC 参数绑定民航订票的首页核心操作就是查航班。查询条件通常是三个出发城市、到达城市、出发日期。城市之间一般用模糊匹配因为用户可能输入「北京」「北京市」或拼音缩写但课设阶段做到包含匹配就够了。下面这段是典型的 DAO 实现方式直接用 JDBC 的 PreparedStatement 做参数绑定String sql SELECT flight_id, flight_no, dep_city, arr_city, dep_time, arr_time, ticket_price, remaining_seats FROM t_flight WHERE dep_city LIKE ? AND arr_city LIKE ? AND DATE(dep_time) ? ORDER BY dep_time; try (PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, % depCity %); ps.setString(2, % arrCity %); ps.setString(3, depDate); // 格式 YYYY-MM-DD ResultSet rs ps.executeQuery(); // 封装成 ListFlight }逻辑说明前三行拼接了查询条件城市字段用LIKE加前后通配符实现包含匹配日期字段用DATE(dep_time)把 datetime 的航班时间截断到天再比较这样用户选 2025-06-01就能查出 2025-06-01 当天所有起飞的航班。SQL 与 Java 交互点全部走setString参数绑定不拼字符串能避开 SQL 注入。参数说明depCity和arrCity为空时要提前判空否则%%会把所有航班都查出来看起来像 bug。depDate必须在 Service 层统一格式化成YYYY-MM-DD如果直接用前端传的2025/06/01会导致日期比较失效。ORDER BY dep_time让结果按起飞时间排序这个排序字段在表结构设计时就应该建索引。3.2 余票扣减条件更新比「先查后改」可靠订票最核心的问题是防超卖。很多人写余票逻辑是「先查询余票判断大于 0再 UPDATE 减 1」。这在单用户测试时没问题但两个用户同时下单时两个请求都读到余票 1都走完判断然后都执行 UPDATE余票就变成了 -1。这个问题的根源是「读」和「写」之间不是一个原子操作。正确的课设写法是把判断和扣减合并成一条 UPDATE利用受影响行数来判断是否成功String deductSql UPDATE t_flight SET remaining_seats remaining_seats - 1 WHERE flight_id ? AND remaining_seats 0; int affected flightDao.update(deductSql, flightId); if (affected 0) { throw new BusinessException(抱歉该航班余票不足); }逻辑说明remaining_seats 0放在 WHERE 条件里后数据库层面的行锁会保证两个并发请求同时走到这条 SQL 时只有一个能成功。失败的那一个 UPDATE 影响的记录数是 0就能立刻抛出异常。这条 SQL 把「判断余票不足」和「扣减余票」合并成一步是 JDBC 场景下最简洁也最稳妥的防超卖方案。参数说明affected是 JDBC 执行 UPDATE 后返回的受影响行数。MySQL 默认情况下只要这条 UPDATE 真正修改了行数据返回就是 1如果条件不满足返回 0。要注意如果remaining_seats减一后值没变化的情况不存在所以不需要刻意设置useAffectedRows连接参数。如果你想做得更严谨可以把总座位数也作为条件加进去比如AND remaining_seats total_seats不过实际业务里total_seats不参与扣减加了反而多余。3.3 订单状态流转与余票释放事务边界收紧到哪一层扣减余票之后紧接着要插入订单记录。这两步必须包在同一个数据库事务里如果订单插入失败余票却扣了用户会看到「下单失败但票没了」反过来订单成功但余票没扣就会出现超卖。经典的事务边界写法如下Connection conn null; try { conn dataSource.getConnection(); conn.setAutoCommit(false); // 1. 条件扣减余票 int affected updateFlightRemainingSeats(conn, flightId); if (affected 0) { throw new BusinessException(余票不足); } // 2. 插入订单 insertOrder(conn, order); conn.commit(); } catch (Exception e) { if (conn ! null) { conn.rollback(); } throw e; } finally { if (conn ! null) { conn.setAutoCommit(true); conn.close(); } }逻辑说明setAutoCommit(false)之后扣减余票和插入订单这两个操作就不再各自立即提交而是等commit()一次性提交。中间任何一步抛异常rollback()会把余票扣减撤销。事务关闭后把自动提交恢复成true并归还连接这是连接池场景下最容易漏掉的一步。参数说明事务必须放在 Service 层而不是 DAO 层。如果放在 DAO 里每个 DAO 方法各开各的事务两个 DAO 之间的操作就无法保持一致。DataSource 的获取方式源码里如果是 C3P0一般是new ComboPooledDataSource()加载c3p0-config.xml如果是 Druid则是DruidDataSourceFactory.createDataSource(properties)。这两种连接池的事务 API 是通用的都是标准 JDBC。取消订单的逻辑和订票是镜像关系先把订单状态改成已取消再把航班余票加回来。这两步同样要在事务里否则会出现订单取消了但余票没恢复。状态流转建议用常量类或枚举别在代码里散落一堆魔法数字。public class OrderStatus { public static final int PENDING 0; // 已预订未支付 public static final int PAID 1; // 已支付已出票 public static final int CANCELLED 2; // 已取消 public static final int REFUNDED 3; // 已退票 }4. 部署运行JDK、Tomcat、MySQL 版本匹配与连接配置4.1 环境选型为什么 JDK 8 Tomcat 9 MySQL 5.7/8 最稳改造这类 Java Web 课设源码时环境版本选对基本就成功了一半。最常见的「翻车现场」是拿 JDK 17 配 Tomcat 10然后源码里但凡用了老式 Servlet 写法就各种编译报错。我的建议是固定三件套JDK 8、Tomcat 9、MySQL 5.7 或者 8.0。JDK 8 是 Java Web 课设兼容性最好的版本无论源码用的 C3P0、DBUtils 还是手动 JDBC都能直接编译。Tomcat 9 对应 Servlet 4.0 规范类名还是javax.servlet老代码不用改包名。MySQL 5.7 和 8.0 区别主要在驱动类名和连接 URL这个在 4.2 节说清楚。如果你本机装的是高版本 JDK 或新 Tomcat不建议卸载重装解决方式是给项目单独配一个运行环境。IDEA 里可以在 Project Structure 里指定 SDK 版本Run Configuration 里指定 Tomcat 的安装路径。跑不起来的时候先检查当前用的是哪个 JDK很多「代码没问题但启动报错」的情况都是版本错配。4.2 数据库导入与 JDBC 连接参数四个 key 一个都不能错导入数据库的方式有两种命令行和图形化工具。命令行方式是直接把文档附带的 SQL 脚本导入mysql -u root -p airline.sql如果提示找不到文件路径先 cd 到 SQL 文件所在目录再执行。导入成功后可以用mysql -u root -p -e show tables验证表是否都建出来了。用 Navicat 或 DBeaver 则更直观新建数据库字符集选 utf8mb4然后在查询窗口直接运行 SQL 脚本。JDBC 连接参数这里展开写一下。源码里通常会有一个jdbc.properties或db.properties文件也可能是c3p0-config.xml里直接写。老式风格配置如下drivercom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/airline?useSSLfalsecharacterEncodingutf8serverTimezoneAsia/Shanghai usernameroot password123456逻辑说明driver 那行MySQL 5.7 用com.mysql.jdbc.DriverMySQL 8.0 用com.mysql.cj.jdbc.Driver。如果你用的是 MySQL 8 却写了 5.7 的驱动会直接报找不到驱动类。url 中的airline是数据库名必须改成你在 4.2 节实际建的库名这里不一致登录页面都打不开。参数说明useSSLfalse是去除 MySQL 8 默认的 SSL 警告characterEncodingutf8是保证写入的中文不乱码serverTimezoneAsia/Shanghai是解决中国大陆时区导致的日期时间差 8 小时问题。这三个参数是复现课程设计时必带的缺一个就会出现特定错误。password 要改成你本机 MySQL 的真实密码很多源码包里留的是root或123456但每个人的环境不一样。4.3 IDEA 导入、部署与访问路径调整导入这一步用 IDEA 的方式是File - New - Project from Existing Sources然后选中源码所在目录。IDEA 会识别是不是 Maven 项目如果源码包里有pom.xml就按 Maven 导入耐心等依赖下载没有 pom.xml 则是普通 Web 项目需要手动配置 Artifact。部署到 Tomcat 的步骤大致是先点Run - Edit Configurations新增一个Tomcat Server - Local在Deployment页签把项目 Artifact 添加进去Application context 一般写/airline或/。如果写/访问地址就是http://localhost:8080/如果写了/airline访问地址就是http://localhost:8080/airline/。这种路径大小写敏感漏写一个字母都会 404。访问之前还需要确认一件事项目里有没有登录页或首页的跳转配置。翻web.xml里的welcome-file-list如果没有配置访问根路径会列目录或 404。此时直接在地址栏输入登录页 JSP 的完整路径比如http://localhost:8080/airline/login.jsp就能绕过首页问题。启动时如果控制台报错优先看第一行SEVERE后面跟着的Caused by才是真正的根因。5. 避坑从解压到答辩五个高频「现场翻车」记录5.1 启动报 ClassNotFoundException: javax.servlet.*现象项目导入成功后点击运行 Tomcat控制台抛java.lang.ClassNotFoundException: javax.servlet.http.HttpServlet或编译期直接标红javax.servlet这个包。原因Tomcat 10 开始使用 Jakarta EE 规范Servlet 包名从javax.servlet变成了jakarta.servlet。老课设源码都是按javax.servlet写的在 Tomcat 10 下根本找不到类。解决把运行配置里的 Tomcat 从 10 换回 9。如果你只有 Tomcat 10可以在项目里加一个javax.servlet-api.jar依赖到WEB-INF/lib也可以强行让老源码在 Tomcat 10 跑起来但这样会遇到更多兼容问题不如直接换 Tomcat 9 省事。5.2 JDBC 报 SSL 连接警告或时区错误现象启动后后台报SSL connection警告或者抛异常The server time zone value Öйú±ê׼ʱ¼ä is unrecognized然后数据库操作全部失败。原因MySQL 8 默认开启 SSL 校验同时驱动要求连接串里指定时区否则就用系统默认值而这个默认值对 MySQL 来说不可识别。解决在jdbc.properties的 url 里补上useSSLfalse和serverTimezoneAsia/Shanghai。如果改了还是报时区错检查一下是不是把参数写在了中文环境下的引号里或 url 里不小心用了全角等号。5.3 数据看板中文全是问号 ???现象系统能登录但前台页面显示的中文内容变成??或者提交中文用户名后数据库里存的也是问号。原因两处字符集不一致。第一处是数据库本身建库时用了默认 latin1第二处是 JDBC 连接的characterEncoding没有设置MySQL 驱动用了客户端默认的字符集。解决先确认建库语句是否包含DEFAULT CHARACTER SET utf8mb4。已建好的库可以执行ALTER DATABASE airline CHARACTER SET utf8mb4;。然后在 JDBC url 里加characterEncodingutf8。最后检查 JSP 页面头部的pageEncoding三层都统一成 UTF-8中文问题基本就绝迹了。5.4 Tomcat 或 MySQL 端口被占用导致启动失败现象启动 Tomcat 时控制台报Port 8080 required by Tomcat... is already in use或 MySQL 连接时报Access denied但密码明明没错。原因8080 端口被本机其他服务占用了这种情况在同时开着 Nginx 或别的 Web 服务时非常常见。MySQL 那边常见的是本机装了多个 MySQL 实例3306 被旧实例占用。解决Tomcat 改端口最快编辑conf/server.xml把 Connector 节点的port8080改成 8081 或 9090重启后访问地址跟着变。MySQL 那边先用netstat -ano | findstr 3306Windows或lsof -i:3306macOS/Linux看谁占着端口再决定停服务还是换端口。5.5 并发订票时余票出现负数或订单数据对不上现象用两个浏览器同时下单同一航班两个订单都成功了但航班的remaining_seats变成了负数或者付款后订单状态还是 0。原因代码里写的是「先 SELECT 查余票再 UPDATE 扣减」中间没有事务包裹。两个线程都读到余票是 1都认为自己买到了。付款回调没把状态改掉则是更新状态和扣款不在一个事务里。解决把扣减改成 3.2 节的条件更新写法并在 Service 层把「扣余票 插订单」包进同一个事务。订单状态不对的问题检查一下支付回调的 Service 方法是不是单独开了新事务或者干脆没调更新语句。这一条是答辩时最容易暴露的业务逻辑扣分点自己提前用多窗口实测一遍。6. 进阶验证事务与三个能加分的代码习惯验证事务边界是不是真的生效不需要并发压测工具自己写一个临时测试类就行。核心做法是直接调用 Service 的订票方法然后在 Service 里故意在插入订单后抛一个异常看事务是否回滚。回滚成功的标志很简单执行前查一次航班余票数量执行后查还是同一个数同时订单表里新增的记录数为 0。如果余票减了但订单没插入说明事务根本没包住这两步。我一般会在项目里临时加一个 JSP 页面或 Test 类来做这个验证测完再删掉。这样做的好处是把「事务是否存在」这个问题变成可以肉眼验证的事实。比起写一堆概念性文字答辩时直接跑一遍「模拟失败回滚」的操作说服力强很多。剩下三个代码习惯是这类课设资源最容易往上加分的点。第一个是订单号生成策略不建议用自增 ID 做订单号可以在insertOrder之前用「时间戳 用户 ID 后四位 航班号后两位」拼一个字符串订单号并给order_no加唯一索引能看出作者考虑过重复问题。第二个是状态常量不要散落数字我在 3.3 节展示了OrderStatus的写法这是设计模式里最基本的常量集中管理答辩提问「订单状态怎么设计的」时可以顺手讲出来。第三个是给 DAO 的增删改查加日志输出用System.out.println或 Java 自带的java.util.logging都行至少每次订票成功、取消成功打一行日志排错时不需要靠猜。这三件事改动量都很小但不影响系统原有功能属于「安全加分项」。顺便说一句如果你的源码里事务已经用了 Spring 的Transactional那不要重复手写 Connection 事务两套混用反而会出现事务失效的怪问题。从那以后我拿到任何课设源码包第一件事永远是先看建库脚本和 JDBC 配置再启动 Tomcat这个顺序帮我避开了至少一半的翻车现场。剩下的一半就是老老实实扣事务边界并亲手验证一遍回滚。希望帮到你。本文还有配套的精品资源点击获取 民航订票管理系统Java课程设计：从文档到部署的完整避坑指南
简介一套民航订票管理系统完整项目资料面向课程设计、毕业设计及桌面应用开发初学者。系统覆盖航班信息查询、客户订票退票、航班与航线管理、航班延误处理、已订票客户和会员信息管理等业务模块采用Java Swing构建图形界面配合JDBC访问SQL Server数据库可在Eclipse或IntelliJ IDEA中直接运行调试。压缩包内含118个文件以Java源码、编译生成的class字节码、XML配置、SQL数据库脚本和docx设计文档为主体另有项目配置与说明等辅助文件整体大小2.29MB结构紧凑便于学习。项目内类与方法命名规范模块边界清楚便于二次开发与功能扩展。资料中的源码与文档贴近实际课程设计场景能帮助读者理解Swing界面编程、JDBC数据操作及分层设计思路也可作为同类订票系统的开发参考或答辩素材。目前已有1816人学习下载对快速上手Java数据库应用开发很有帮助。1. 民航订票管理系统拿到手这个 zip 里真正值得花时间的东西课程设计和毕设季民航订票管理系统设计文档这类 Java 压缩包满天飞。我在帮人改这类源码的时候发现一个规律九成的人卡住不是因为代码跑不起来而是不知道该先看文档还是先跑代码。这份资源的核心价值其实不是某段精妙的代码而是「设计文档 实现源码」能对上——需求分析里写的订票流程在数据库表里能找到字段在 DAO 里能找到对应的 SQL。适合三类人拿它做课程设计交作业的在校生、需要快速搭一个 Java Web 课设 Demo 的从业者以及想搞懂「一个业务系统从文档到代码怎么落地」的初学者。这篇文章按我拆项目的习惯把解压、建库、部署、验证的顺序和每个环节的坑一次讲完。2. 设计文档先行先读懂业务边界再决定改哪里2.1 文档包的常规布局需求、设计、答辩三类文件怎么分工这类资源包解压之后常见会有一份「设计文档」或「课程设计报告」目录里面通常包含三类文件需求分析、数据库设计、详细设计。很多人习惯跳过文档直接开 IDEA结果是代码启动失败后回头翻文档翻半天找不到对应知识点。我的习惯是倒过来先用 20 分钟把文档目录扫一遍确认三件事。第一需求分析里的角色和业务流程。民航订票系统最常见的是三种角色游客、注册用户、管理员或后台管理员。游客能查航班但不能下单注册用户可以订票、取消订单管理员维护航班和舱位信息。文档里只要把这三类角色的用例和操作边界写清楚了你就能判断源码里该有哪几个控制器Controller 或 Servlet。第二数据库设计里的 E-R 图和表结构清单。这一部分直接决定了你在 MySQL 里要建几张表、表之间怎么关联。常见的民航订票系统是六到八张表核心是用户表、航班表、订单表往外延伸有乘机人表、舱位表、机场表、退票或改签记录表。读表结构的时候重点看主外键和唯一约束这比看字段列表更省时间。第三详细设计里的分层结构和接口说明。Java Web 课设哪怕不用 Spring也基本会走 Servlet JSP JDBC 或 DAO 模式。文档里如果有类图和时序图直接照图去源码里找对应类比逐个文件打开快得多。如果文档不全就用「一条订票链路」去反推系统分层这个我放在 2.3 节详细说。提示拿到资源先花十几分钟确认文档版本和代码版本一致。有的压缩包文档更新过但代码没同步导致表名字段对不上这种不匹配浪费的时间比排错还多。2.2 核心表结构拆解一条业务线写到 t_flight / t_order 里的关键字段民航订票系统的数据模型本质上是「航班余票」和「订单状态」两个维度的建模。文档里如果只有一张 E-R 图你可以自己补一张字段清单因为后面写代码、连数据库、跑 SQL 全靠它。先看航班表通常叫 t_flight 或 flight 表字段大体包括字段名类型建议作用flight_idint 或 varchar主键航班内部 IDflight_novarchar航班号如 CA1801对外展示用dep_city / arr_cityvarchar起降城市查询的核心过滤条件dep_time / arr_timedatetime起降时间一般 dep_time 建索引cabin 或 seat_typevarchar/int舱位等级如经济舱、头等舱ticket_pricedecimal票价注意用 decimal 不用 floattotal_seatsint该航班该舱位总座位数remaining_seatsint余票数订票扣减的关键字段这里最容易踩坑的是 total_seats 和 remaining_seats 分开存。有些人省事只在订单表里统计数量最后发现余票算不准还要 JOIN 订单表去做减法并发一高就会出现负数。文档里只要有这两个字段后面订票逻辑就可以用条件更新一行 SQL 搞定这个我在第 3 章详细写。再看订单表常见命名 t_order字段名类型建议作用order_idint 自增主键order_novarchar订单号对外展示一般要加唯一索引user_idint下单用户外键关联用户表flight_idint关联航班表statustinyint订单状态0 未支付 / 1 已出票 / 2 已取消 / 3 已退票create_timedatetime下单时间pay_timedatetime支付时间允许为空订单号加唯一索引这一点很多课设源码里没有。没有唯一索引理论上同一毫秒生成相同订单号插入时不会有任何报错排查问题时无从下手。文档如果没提建议自己在建表脚本里补上。民航订票和普通电商订单类似status 字段是最容易被写死的——有人用 0/1 判断有人用 payed/canceled 字符串哪种都行但必须在文档里写清楚约定。2.3 从 E-R 图到代码包用「一条订票链路」定位三层代码拿到源码包之后建议第一步不要按目录从上往下读而是选一条最核心的业务链路——订票链路用户登录、查航班、下单、扣余票、生成订单。沿着这条链路在源码里走一遍整个项目的分层就全清楚了。最典型的 Java Web 三层结构是这样对应的表现层JSP 页面 Servlet或 Controller。对应源码里的views目录和servlet/controller包。登录、查询表单在这里提交跳转逻辑由这里接管。业务层Service 类。对应订票流程里的「校验用户、校验航班、调用 DAO 扣减余票、插入订单」这一串动作。源码里如果直接由 Servlet 调 DAO 而没有 Service 层说明项目可能偏简单。数据层DAOData Access Object。对应每个数据库操作比如FlightDao、OrderDao、UserDao。DAO 里放的是 JDBC 或 DBUtils 的 SQL 执行代码。我一般会先在源码里搜两个关键词Connection和PreparedStatement。如果能在同一个包下看到这些类说明就是经典的 JDBC 直连方案如果看到druid或c3p0配置说明用了连接池。这两种方案的配置入口不一样运行时的错误特征也不一样后面部署章节会区分讲。搜完之后再看web.xml或webapp目录确认 Servlet 映射的 URL 规则比如/login、/searchFlight、/bookTicket分别对应哪个类。这一步做完你基本就知道改哪个文件能影响哪段业务而不是靠猜。3. 订票逻辑实现航班查询、余票扣减与订单状态流转3.1 航班查询模糊匹配与出行日期的 JDBC 参数绑定民航订票的首页核心操作就是查航班。查询条件通常是三个出发城市、到达城市、出发日期。城市之间一般用模糊匹配因为用户可能输入「北京」「北京市」或拼音缩写但课设阶段做到包含匹配就够了。下面这段是典型的 DAO 实现方式直接用 JDBC 的 PreparedStatement 做参数绑定String sql SELECT flight_id, flight_no, dep_city, arr_city, dep_time, arr_time, ticket_price, remaining_seats FROM t_flight WHERE dep_city LIKE ? AND arr_city LIKE ? AND DATE(dep_time) ? ORDER BY dep_time; try (PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, % depCity %); ps.setString(2, % arrCity %); ps.setString(3, depDate); // 格式 YYYY-MM-DD ResultSet rs ps.executeQuery(); // 封装成 ListFlight }逻辑说明前三行拼接了查询条件城市字段用LIKE加前后通配符实现包含匹配日期字段用DATE(dep_time)把 datetime 的航班时间截断到天再比较这样用户选 2025-06-01就能查出 2025-06-01 当天所有起飞的航班。SQL 与 Java 交互点全部走setString参数绑定不拼字符串能避开 SQL 注入。参数说明depCity和arrCity为空时要提前判空否则%%会把所有航班都查出来看起来像 bug。depDate必须在 Service 层统一格式化成YYYY-MM-DD如果直接用前端传的2025/06/01会导致日期比较失效。ORDER BY dep_time让结果按起飞时间排序这个排序字段在表结构设计时就应该建索引。3.2 余票扣减条件更新比「先查后改」可靠订票最核心的问题是防超卖。很多人写余票逻辑是「先查询余票判断大于 0再 UPDATE 减 1」。这在单用户测试时没问题但两个用户同时下单时两个请求都读到余票 1都走完判断然后都执行 UPDATE余票就变成了 -1。这个问题的根源是「读」和「写」之间不是一个原子操作。正确的课设写法是把判断和扣减合并成一条 UPDATE利用受影响行数来判断是否成功String deductSql UPDATE t_flight SET remaining_seats remaining_seats - 1 WHERE flight_id ? AND remaining_seats 0; int affected flightDao.update(deductSql, flightId); if (affected 0) { throw new BusinessException(抱歉该航班余票不足); }逻辑说明remaining_seats 0放在 WHERE 条件里后数据库层面的行锁会保证两个并发请求同时走到这条 SQL 时只有一个能成功。失败的那一个 UPDATE 影响的记录数是 0就能立刻抛出异常。这条 SQL 把「判断余票不足」和「扣减余票」合并成一步是 JDBC 场景下最简洁也最稳妥的防超卖方案。参数说明affected是 JDBC 执行 UPDATE 后返回的受影响行数。MySQL 默认情况下只要这条 UPDATE 真正修改了行数据返回就是 1如果条件不满足返回 0。要注意如果remaining_seats减一后值没变化的情况不存在所以不需要刻意设置useAffectedRows连接参数。如果你想做得更严谨可以把总座位数也作为条件加进去比如AND remaining_seats total_seats不过实际业务里total_seats不参与扣减加了反而多余。3.3 订单状态流转与余票释放事务边界收紧到哪一层扣减余票之后紧接着要插入订单记录。这两步必须包在同一个数据库事务里如果订单插入失败余票却扣了用户会看到「下单失败但票没了」反过来订单成功但余票没扣就会出现超卖。经典的事务边界写法如下Connection conn null; try { conn dataSource.getConnection(); conn.setAutoCommit(false); // 1. 条件扣减余票 int affected updateFlightRemainingSeats(conn, flightId); if (affected 0) { throw new BusinessException(余票不足); } // 2. 插入订单 insertOrder(conn, order); conn.commit(); } catch (Exception e) { if (conn ! null) { conn.rollback(); } throw e; } finally { if (conn ! null) { conn.setAutoCommit(true); conn.close(); } }逻辑说明setAutoCommit(false)之后扣减余票和插入订单这两个操作就不再各自立即提交而是等commit()一次性提交。中间任何一步抛异常rollback()会把余票扣减撤销。事务关闭后把自动提交恢复成true并归还连接这是连接池场景下最容易漏掉的一步。参数说明事务必须放在 Service 层而不是 DAO 层。如果放在 DAO 里每个 DAO 方法各开各的事务两个 DAO 之间的操作就无法保持一致。DataSource 的获取方式源码里如果是 C3P0一般是new ComboPooledDataSource()加载c3p0-config.xml如果是 Druid则是DruidDataSourceFactory.createDataSource(properties)。这两种连接池的事务 API 是通用的都是标准 JDBC。取消订单的逻辑和订票是镜像关系先把订单状态改成已取消再把航班余票加回来。这两步同样要在事务里否则会出现订单取消了但余票没恢复。状态流转建议用常量类或枚举别在代码里散落一堆魔法数字。public class OrderStatus { public static final int PENDING 0; // 已预订未支付 public static final int PAID 1; // 已支付已出票 public static final int CANCELLED 2; // 已取消 public static final int REFUNDED 3; // 已退票 }4. 部署运行JDK、Tomcat、MySQL 版本匹配与连接配置4.1 环境选型为什么 JDK 8 Tomcat 9 MySQL 5.7/8 最稳改造这类 Java Web 课设源码时环境版本选对基本就成功了一半。最常见的「翻车现场」是拿 JDK 17 配 Tomcat 10然后源码里但凡用了老式 Servlet 写法就各种编译报错。我的建议是固定三件套JDK 8、Tomcat 9、MySQL 5.7 或者 8.0。JDK 8 是 Java Web 课设兼容性最好的版本无论源码用的 C3P0、DBUtils 还是手动 JDBC都能直接编译。Tomcat 9 对应 Servlet 4.0 规范类名还是javax.servlet老代码不用改包名。MySQL 5.7 和 8.0 区别主要在驱动类名和连接 URL这个在 4.2 节说清楚。如果你本机装的是高版本 JDK 或新 Tomcat不建议卸载重装解决方式是给项目单独配一个运行环境。IDEA 里可以在 Project Structure 里指定 SDK 版本Run Configuration 里指定 Tomcat 的安装路径。跑不起来的时候先检查当前用的是哪个 JDK很多「代码没问题但启动报错」的情况都是版本错配。4.2 数据库导入与 JDBC 连接参数四个 key 一个都不能错导入数据库的方式有两种命令行和图形化工具。命令行方式是直接把文档附带的 SQL 脚本导入mysql -u root -p airline.sql如果提示找不到文件路径先 cd 到 SQL 文件所在目录再执行。导入成功后可以用mysql -u root -p -e show tables验证表是否都建出来了。用 Navicat 或 DBeaver 则更直观新建数据库字符集选 utf8mb4然后在查询窗口直接运行 SQL 脚本。JDBC 连接参数这里展开写一下。源码里通常会有一个jdbc.properties或db.properties文件也可能是c3p0-config.xml里直接写。老式风格配置如下drivercom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/airline?useSSLfalsecharacterEncodingutf8serverTimezoneAsia/Shanghai usernameroot password123456逻辑说明driver 那行MySQL 5.7 用com.mysql.jdbc.DriverMySQL 8.0 用com.mysql.cj.jdbc.Driver。如果你用的是 MySQL 8 却写了 5.7 的驱动会直接报找不到驱动类。url 中的airline是数据库名必须改成你在 4.2 节实际建的库名这里不一致登录页面都打不开。参数说明useSSLfalse是去除 MySQL 8 默认的 SSL 警告characterEncodingutf8是保证写入的中文不乱码serverTimezoneAsia/Shanghai是解决中国大陆时区导致的日期时间差 8 小时问题。这三个参数是复现课程设计时必带的缺一个就会出现特定错误。password 要改成你本机 MySQL 的真实密码很多源码包里留的是root或123456但每个人的环境不一样。4.3 IDEA 导入、部署与访问路径调整导入这一步用 IDEA 的方式是File - New - Project from Existing Sources然后选中源码所在目录。IDEA 会识别是不是 Maven 项目如果源码包里有pom.xml就按 Maven 导入耐心等依赖下载没有 pom.xml 则是普通 Web 项目需要手动配置 Artifact。部署到 Tomcat 的步骤大致是先点Run - Edit Configurations新增一个Tomcat Server - Local在Deployment页签把项目 Artifact 添加进去Application context 一般写/airline或/。如果写/访问地址就是http://localhost:8080/如果写了/airline访问地址就是http://localhost:8080/airline/。这种路径大小写敏感漏写一个字母都会 404。访问之前还需要确认一件事项目里有没有登录页或首页的跳转配置。翻web.xml里的welcome-file-list如果没有配置访问根路径会列目录或 404。此时直接在地址栏输入登录页 JSP 的完整路径比如http://localhost:8080/airline/login.jsp就能绕过首页问题。启动时如果控制台报错优先看第一行SEVERE后面跟着的Caused by才是真正的根因。5. 避坑从解压到答辩五个高频「现场翻车」记录5.1 启动报 ClassNotFoundException: javax.servlet.*现象项目导入成功后点击运行 Tomcat控制台抛java.lang.ClassNotFoundException: javax.servlet.http.HttpServlet或编译期直接标红javax.servlet这个包。原因Tomcat 10 开始使用 Jakarta EE 规范Servlet 包名从javax.servlet变成了jakarta.servlet。老课设源码都是按javax.servlet写的在 Tomcat 10 下根本找不到类。解决把运行配置里的 Tomcat 从 10 换回 9。如果你只有 Tomcat 10可以在项目里加一个javax.servlet-api.jar依赖到WEB-INF/lib也可以强行让老源码在 Tomcat 10 跑起来但这样会遇到更多兼容问题不如直接换 Tomcat 9 省事。5.2 JDBC 报 SSL 连接警告或时区错误现象启动后后台报SSL connection警告或者抛异常The server time zone value Öйú±ê׼ʱ¼ä is unrecognized然后数据库操作全部失败。原因MySQL 8 默认开启 SSL 校验同时驱动要求连接串里指定时区否则就用系统默认值而这个默认值对 MySQL 来说不可识别。解决在jdbc.properties的 url 里补上useSSLfalse和serverTimezoneAsia/Shanghai。如果改了还是报时区错检查一下是不是把参数写在了中文环境下的引号里或 url 里不小心用了全角等号。5.3 数据看板中文全是问号 ???现象系统能登录但前台页面显示的中文内容变成??或者提交中文用户名后数据库里存的也是问号。原因两处字符集不一致。第一处是数据库本身建库时用了默认 latin1第二处是 JDBC 连接的characterEncoding没有设置MySQL 驱动用了客户端默认的字符集。解决先确认建库语句是否包含DEFAULT CHARACTER SET utf8mb4。已建好的库可以执行ALTER DATABASE airline CHARACTER SET utf8mb4;。然后在 JDBC url 里加characterEncodingutf8。最后检查 JSP 页面头部的pageEncoding三层都统一成 UTF-8中文问题基本就绝迹了。5.4 Tomcat 或 MySQL 端口被占用导致启动失败现象启动 Tomcat 时控制台报Port 8080 required by Tomcat... is already in use或 MySQL 连接时报Access denied但密码明明没错。原因8080 端口被本机其他服务占用了这种情况在同时开着 Nginx 或别的 Web 服务时非常常见。MySQL 那边常见的是本机装了多个 MySQL 实例3306 被旧实例占用。解决Tomcat 改端口最快编辑conf/server.xml把 Connector 节点的port8080改成 8081 或 9090重启后访问地址跟着变。MySQL 那边先用netstat -ano | findstr 3306Windows或lsof -i:3306macOS/Linux看谁占着端口再决定停服务还是换端口。5.5 并发订票时余票出现负数或订单数据对不上现象用两个浏览器同时下单同一航班两个订单都成功了但航班的remaining_seats变成了负数或者付款后订单状态还是 0。原因代码里写的是「先 SELECT 查余票再 UPDATE 扣减」中间没有事务包裹。两个线程都读到余票是 1都认为自己买到了。付款回调没把状态改掉则是更新状态和扣款不在一个事务里。解决把扣减改成 3.2 节的条件更新写法并在 Service 层把「扣余票 插订单」包进同一个事务。订单状态不对的问题检查一下支付回调的 Service 方法是不是单独开了新事务或者干脆没调更新语句。这一条是答辩时最容易暴露的业务逻辑扣分点自己提前用多窗口实测一遍。6. 进阶验证事务与三个能加分的代码习惯验证事务边界是不是真的生效不需要并发压测工具自己写一个临时测试类就行。核心做法是直接调用 Service 的订票方法然后在 Service 里故意在插入订单后抛一个异常看事务是否回滚。回滚成功的标志很简单执行前查一次航班余票数量执行后查还是同一个数同时订单表里新增的记录数为 0。如果余票减了但订单没插入说明事务根本没包住这两步。我一般会在项目里临时加一个 JSP 页面或 Test 类来做这个验证测完再删掉。这样做的好处是把「事务是否存在」这个问题变成可以肉眼验证的事实。比起写一堆概念性文字答辩时直接跑一遍「模拟失败回滚」的操作说服力强很多。剩下三个代码习惯是这类课设资源最容易往上加分的点。第一个是订单号生成策略不建议用自增 ID 做订单号可以在insertOrder之前用「时间戳 用户 ID 后四位 航班号后两位」拼一个字符串订单号并给order_no加唯一索引能看出作者考虑过重复问题。第二个是状态常量不要散落数字我在 3.3 节展示了OrderStatus的写法这是设计模式里最基本的常量集中管理答辩提问「订单状态怎么设计的」时可以顺手讲出来。第三个是给 DAO 的增删改查加日志输出用System.out.println或 Java 自带的java.util.logging都行至少每次订票成功、取消成功打一行日志排错时不需要靠猜。这三件事改动量都很小但不影响系统原有功能属于「安全加分项」。顺便说一句如果你的源码里事务已经用了 Spring 的Transactional那不要重复手写 Connection 事务两套混用反而会出现事务失效的怪问题。从那以后我拿到任何课设源码包第一件事永远是先看建库脚本和 JDBC 配置再启动 Tomcat这个顺序帮我避开了至少一半的翻车现场。剩下的一半就是老老实实扣事务边界并亲手验证一遍回滚。希望帮到你。本文还有配套的精品资源点击获取