简介：一套民航订票管理系统完整项目资料，面向课程设计、毕业设计及桌面应用开发初学者。系统覆盖航班信息查询、客户订票退票、航班与航线管理、航班延误处理、已订票客户和会员信息管理等业务模块，采用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_id | int 或 varchar | 主键，航班内部 ID |
| flight_no | varchar | 航班号，如 CA1801，对外展示用 |
| dep_city / arr_city | varchar | 起降城市，查询的核心过滤条件 |
| dep_time / arr_time | datetime | 起降时间，一般 dep_time 建索引 |
| cabin 或 seat_type | varchar/int | 舱位等级，如经济舱、头等舱 |
| ticket_price | decimal | 票价，注意用 decimal 不用 float |
| total_seats | int | 该航班该舱位总座位数 |
| remaining_seats | int | 余票数，订票扣减的关键字段 |
这里最容易踩坑的是 total_seats 和 remaining_seats 分开存。有些人省事，只在订单表里统计数量，最后发现余票算不准，还要 JOIN 订单表去做减法，并发一高就会出现负数。文档里只要有这两个字段，后面订票逻辑就可以用条件更新一行 SQL 搞定，这个我在第 3 章详细写。
再看订单表（常见命名 t_order）
| 字段名 | 类型建议 | 作用 |
|---|---|---|
| order_id | int 自增 | 主键 |
| order_no | varchar | 订单号，对外展示，一般要加唯一索引 |
| user_id | int | 下单用户，外键关联用户表 |
| flight_id | int | 关联航班表 |
| status | tinyint | 订单状态：0 未支付 / 1 已出票 / 2 已取消 / 3 已退票 |
| create_time | datetime | 下单时间 |
| pay_time | datetime | 支付时间，允许为空 |
订单号加唯一索引这一点，很多课设源码里没有。没有唯一索引，理论上同一毫秒生成相同订单号插入时不会有任何报错，排查问题时无从下手。文档如果没提，建议自己在建表脚本里补上。民航订票和普通电商订单类似，status 字段是最容易被写死的——有人用 0/1 判断，有人用 "payed"/"canceled" 字符串，哪种都行，但必须在文档里写清楚约定。
2.3 从 E-R 图到代码包：用「一条订票链路」定位三层代码
拿到源码包之后，建议第一步不要按目录从上往下读，而是选一条最核心的业务链路——订票链路：用户登录、查航班、下单、扣余票、生成订单。沿着这条链路在源码里走一遍，整个项目的分层就全清楚了。
最典型的 Java Web 三层结构是这样对应的：
- 表现层：JSP 页面 + Servlet（或 Controller）。对应源码里的
views目录和servlet/controller包。登录、查询表单在这里提交，跳转逻辑由这里接管。 - 业务层：Service 类。对应订票流程里的「校验用户、校验航班、调用 DAO 扣减余票、插入订单」这一串动作。源码里如果直接由 Servlet 调 DAO 而没有 Service 层，说明项目可能偏简单。
- 数据层：DAO（Data 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(); // 封装成 List<Flight> }逻辑说明：前三行拼接了查询条件，城市字段用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里直接写。老式风格配置如下：
driver=com.mysql.cj.jdbc.Driver url=jdbc:mysql://localhost:3306/airline?useSSL=false&characterEncoding=utf8&serverTimezone=Asia/Shanghai username=root password=123456逻辑说明：driver 那行，MySQL 5.7 用com.mysql.jdbc.Driver，MySQL 8.0 用com.mysql.cj.jdbc.Driver。如果你用的是 MySQL 8 却写了 5.7 的驱动，会直接报找不到驱动类。url 中的airline是数据库名，必须改成你在 4.2 节实际建的库名，这里不一致登录页面都打不开。
参数说明：useSSL=false是去除 MySQL 8 默认的 SSL 警告；characterEncoding=utf8是保证写入的中文不乱码；serverTimezone=Asia/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 里补上useSSL=false和serverTimezone=Asia/Shanghai。如果改了还是报时区错，检查一下是不是把参数写在了中文环境下的引号里，或 url 里不小心用了全角等号。
5.3 数据看板中文全是问号 ???
现象：系统能登录，但前台页面显示的中文内容变成??，或者提交中文用户名后数据库里存的也是问号。
原因：两处字符集不一致。第一处是数据库本身建库时用了默认 latin1；第二处是 JDBC 连接的characterEncoding没有设置，MySQL 驱动用了客户端默认的字符集。
解决：先确认建库语句是否包含DEFAULT CHARACTER SET utf8mb4。已建好的库可以执行ALTER DATABASE airline CHARACTER SET utf8mb4;。然后在 JDBC url 里加characterEncoding=utf8。最后检查 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 节点的port="8080"改成 8081 或 9090，重启后访问地址跟着变。MySQL 那边先用netstat -ano | findstr 3306（Windows）或lsof -i:3306（macOS/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，这个顺序帮我避开了至少一半的翻车现场。剩下的一半，就是老老实实扣事务边界，并亲手验证一遍回滚。希望帮到你。
本文还有配套的精品资源，点击获取
