简介基于JSPJava技术栈的机票预订系统源代码包面向Java Web初学者与课程设计、毕业设计人群可帮助理解在线预订业务流程及典型分层架构实现。包内共1644个文件约38.59MB包含JSP页面、Java类、Servlet、DAO组件以及CSS、JavaScript、图片等前端资源还提供SQL脚本与配置文件基本覆盖用户注册登录、航班查询、订单管理等完整功能链路。当前已有156人学习下载。从目录中可看到WEB-INF、classes、lib、css、js等模块分布其中jsp目录集中展示了登录、查询、预订等业务页面classes存放编译后的字节码lib保存依赖jar包便于对照学习项目构建规范。研读源码可掌握Servlet请求响应处理、JavaBean数据封装、DAO与数据库交互、会话管理及MVC分层设计等核心知识点同时了解如何整合前端技术实现动态交互页面对打算独立完成一个Java Web全栈项目的初学者而言是极具参考价值的落地案例。1. JSP 机票预订系统源代码.zip打开压缩包前先做这三件事JSP 机票预订系统源代码.zip 这个包几乎是 JavaWeb 课程设计里流传最广的一类产物一个 Servlet JSP JDBC 三层结构的完整订票系统登录、注册、航班查询、订票、退票、订单管理都齐了。多数人拿到包的第一反应是解压、导入 Eclipse、启动 Tomcat然后在两小时里被一串报错劝退。真正的问题通常不在代码而在环境——JDK、Tomcat、MySQL 驱动、字符集任何一个不匹配页面就集体翻车。下面按部署、拆源码、排坑、改造四条线往下走。先花十分钟把版本对齐再导入数据库脚本比拿到包就双击解压、盲目试错要快得多也适合正要拿它当课程设计、毕业设计或内部后台原型的读者。2. 跑通环境JDK、Tomcat、MySQL 版本怎么定数据库脚本怎么导入2.1 三个环境变量先对齐JDK8、Tomcat9、MySQL 字符集JSP 和 Spring Boot 不一样。Spring Boot 内嵌容器打包后扔上去就能跑JSP 项目要由 Tomcat 里的 Jasper 组件先把 .jsp 翻译成 Servlet 源码再编译成 class 加载。所以 Tomcat 版本实际上决定了 JSP 能用到哪些 Servlet API。老项目里凡是import javax.servlet.http.*的地方在 Tomcat 10 上会全军覆没因为整个包名被改成了jakarta.servlet.*。版本组合是这个项目里最玄学的一环不建议追新用保守组合最省事。常见做法是 JDK8 Tomcat 8.5/9.0 MySQL 5.7 或 8.0。JDK 8 足够应付课程设计里的反射、泛型强转这些写法JDK 17 以上个别老代码会踩到模块化访问限制。Tomcat 9 还在 javax.* 时代和 JSP 传统写法兼容。MySQL 版本影响相对小但 MySQL 8 的驱动参数和认证方式与 5.7 有明显差异这一点放到 2.3 单独讲。组件一般建议为什么JDK8 或 11过高版本会触发模块访问限制老代码里 com.sun.* 用法会编译失败Tomcat8.5 / 9.0使用 javax.* 包名兼容老 web.xml 和 JSP 旧写法MySQL5.7 / 8.0业务量小5.7 更省心8.0 需要配套新驱动数据库驱动与 MySQL 主版本匹配MySQL 8 需要 com.mysql.cj.jdbc.Driver 和相关 URL 参数如果你本机没有 MySQL用 zip 免安装方式初始化开发库是可行的解压压缩包在 mysql 目录下建 data 文件夹执行mysqld --initialize-insecure再用mysqld --console启动。这样不会往系统里注册服务用完直接删目录。还要注意一点IDE 内置的 Tomcat 和独立安装的 Tomcat 是两个环境课程设计源码一般在独立装好的 Tomcat 下更容易跑通。注意JSP 项目的运行环境是个“组合”。先确认三件套再看源码比解压后逐个试错要快得多。2.2 导入数据库脚本建库、建表、初始化航班的几条命令源码包里一般会带一个 .sql 文件位置可能在 db 目录或项目根目录文件名可能是 flight.sql、air.sql。先用文本编辑器打开看一眼确认文件编码和末尾有没有 COMMIT然后执行mysql -uroot -p --default-character-setutf8mb4 db/flight.sql如果 SQL 文件里没有建库语句或者想统一库名先手动建库再导入CREATE DATABASE IF NOT EXISTS air DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE air; SOURCE /absolute/path/db/flight.sql;第一种写法用命令行重定向适合 Linux 和 macOS第二种写法适合已经进入 mysql 客户端时用。导入完成后先确认核心表有数据SELECT COUNT(*) FROM flight;这里有三个细节经常踩坑。第一脚本里如果写了 DROP DATABASE 或 DROP TABLE它只适合第一次导入第二次执行会把你手工插的测试数据全部清掉。第二jdbc.url 里的库名必须和 SQL 里的库名一致常见翻车是库名建成了 flight连接串里写的却是 air。第三可视化工具导入旧版 SQL 时可能把 utf8mb4 的注释弄成乱码不影响查询但对强迫症不友好建议直接用命令行导入。2.3 改数据库连接db.properties 里最容易错的两个参数老 JSP 项目一般把数据库连接写在 src 目录下的 db.properties或者放在 WEB-INF/classes 里。找到它改成下面这样jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/air?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8 jdbc.usernameroot jdbc.password123456driver 这一行是最容易翻车的参数。旧驱动类名 com.mysql.jdbc.Driver 在新驱动里虽然还保留兼容入口但 MySQL 8 的默认认证插件 caching_sha2_password 需要新驱动支持稳妥做法是直接用 com.mysql.cj.jdbc.Driver同时把 WEB-INF/lib 下的 mysql-connector-java.jar 替换成与 MySQL 主版本匹配的新版本避免 ClassNotFound。URL 里三个参数各有用处useSSLfalse 避免本地连接时做 SSL 证书交换不加会拖慢握手并刷出大量连接警告serverTimezoneAsia/Shanghai 是 MySQL 8 驱动解析 DATETIME 时的时区依据不写经常报“The server time zone value”异常characterEncodingutf8 保证连接层字符集注意是 utf8不是 utf-8写反了直接连不上。密码如果带特殊字符properties 里不需要额外转义但项目里有些老代码会把连接配置写在 XML 格式的 context.xml 里那里面的 、:、/ 都需要处理。加载方式不同踩的坑也不同改完配置后一定要重启 Tomcat而不是只刷新页面。2.4 部署到 Tomcat看日志而不是瞎刷新页面部署方式有两种把项目整个目录复制到 Tomcat 的 webapps 下或者打成 war 包放进去。课程设计源码一般是目录结构直接复制最省事cp -r flight /path/to/tomcat/webapps/ cd /path/to/tomcat/bin ./startup.sh tail -f /path/to/tomcat/logs/catalina.outWindows 下对应操作是复制目录到 webapps双击 startup.bat日志在 logs 目录下的 localhost.yyyy-MM-dd.log 文件里。启动后访问 http://localhost:8080/flight/ Tomcat 会自动把目录名映射成上下文路径。用 IDE 导入的项目同样会跑在这套机制上差别只是 IDE 帮你点了一下启动按钮。遇到页面打不开第一反应不要是刷新浏览器而是去看日志日志是这个黑匣子的开口。LifecycleException 通常说明 web.xml 里配置的 Servlet 类找不到检查 WEB-INF/classes 下有没有编译产物Unable to compile class for JSP 说明 JSP 里的 Java 代码有语法错误日志会带行号。老项目经常只把 .java 和 .jsp 复制出来.class 文件没带启动必然失败。翻一下 work/Catalina/localhost/ 下有没有生成编译目录也能快速判断 Tomcat 到底有没有完成部署这一步。血泪经验就一条先看日志再看代码。3. 源码拆解Servlet JSP JDBC 三层里机票业务的代码落在哪3.1 文件结构一览Bean、Servlet、DAO 和 JSP 页面怎么分工这类系统的源码结构非常固定。项目里通常有 src 和 WebContent 两个根src 下按包名放 Java 文件WebContent 下放 JSP、CSS、JS 和 WEB-INF/web.xml。常见分布如下目录/文件存放内容典型类bean / entity与数据库表字段对应的实体类User.java、Flight.java、Order.javadao一个表对应一个 JDBC 访问类UserDao.java、FlightDao.java、OrderDao.javaservlet接收请求、调 DAO、跳转页面LoginServlet.java、FlightListServlet.javafilter跨请求的拦截处理EncodingFilter.java、LoginFilter.javaWebContent 下的 JSP页面展示和表单收集login.jsp、flight_list.jsp、order.jsp分工的逻辑是JSP 只负责把数据渲染成 HTMLServlet 是路由层DAO 是唯一摸数据库的地方。老系统常见的坏味道是 JSP 里同时写了两套逻辑页面里既循环输出航班列表又顺手拼了一条 SQL。看到这种代码不用急着重构先知道它是业务和视图耦合的产物就行。排查问题时按“找 DAO → 找 Servlet → 找 JSP”的顺序基本能覆盖九成情况。还有一个隐性目录值得注意Tomcat 的 work 目录会把每个 JSP 翻译成 _jsp.java再编译成 class。JSP 页面报错时日志里的行号指向的是翻译后的文件对照原 JSP 可以精确定位是哪一行 Java 代码出了问题。这个目录是排查 JSP 编译错误的利器后面 4.5 还会用到。3.2 登录和 Session为什么不建议在 JSP 页面里写 Java 代码登录在老项目里是一个 Servlet 处理 doPost典型代码长这样protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String username req.getParameter(username); String password req.getParameter(password); User user userDao.findByUsernameAndPassword(username, password); if (user ! null) { HttpSession session req.getSession(); session.setAttribute(loginUser, user); session.setMaxInactiveInterval(1800); resp.sendRedirect(index.jsp); } else { req.setAttribute(errorMsg, 用户名或密码错误); req.getRequestDispatcher(login.jsp).forward(req, resp); } }逻辑不复杂从请求里取出用户名和密码调 DAO 查用户表查到就把 User 对象放进 Session并设置会话 30 分钟过期然后重定向到主页查不到就把错误提示放进 request再转发回登录页。整个过程里最容易忽略的是 sendRedirect 和 forward 的区别重定向是 302浏览器会再发一次请求request 里的属性会丢转发是服务器内部调转request 属性保留。所以登录失败用 forward是为了登录页能取到 errorMsg。Session 超时按秒算1800 就是 30 分钟。如果项目里退出登录只做了“隐藏按钮”而没删 session 属性用户在 30 分钟内直接访问订单页依然是登录态这是很多权限漏洞的起点。另外如果 User 表里的 password 是明文存放建议改造时给密码加一层哈希这是所有课程设计代码上生产前的底线。用户个人中心页面在这种项目里往往做得最简单一般就是显示session.getAttribute(loginUser)里的几个字段。你可以在个人信息展示页面里看到 EL 表达式和 JSP 脚本混用的典型写法这也是判断代码耦合度最快的入口。3.3 航班表与订单表机票剩余量怎么设计才不超卖机票业务的核心是两张表航班表和订单表。课程设计里的表结构一般长这样CREATE TABLE flight ( flight_no VARCHAR(20) PRIMARY KEY, from_city VARCHAR(50) NOT NULL, to_city VARCHAR(50) NOT NULL, takeoff_time DATETIME NOT NULL, arrival_time DATETIME NOT NULL, price DECIMAL(10,2) NOT NULL, left_tickets INT NOT NULL ) DEFAULT CHARSETutf8mb4; CREATE TABLE orders ( order_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, flight_no VARCHAR(20) NOT NULL, order_time DATETIME NOT NULL, status TINYINT NOT NULL COMMENT 0待支付 1已出票 2已退票 ) DEFAULT CHARSETutf8mb4;price 用 DECIMAL(10,2) 而不是 FLOAT因为浮点类型做金额运算是二进制近似单笔差价只有几分钱累积对账时就会出问题。left_tickets 是余票数字段订票流程里最常见的实现是先查 left_tickets 是否大于 0再执行UPDATE ... SET left_tickets left_tickets - 1。这个顺序在并发下会超卖两个用户同时查到剩 1 张两个都下单成功实际库存变成负数。更稳妥的做法是让数据库来做判定UPDATE flight SET left_tickets left_tickets - 1 WHERE flight_no ? AND left_tickets 0;受影响行数为 1 再插入订单否则提示余票不足。这个改动很小但对订单正确性影响极大。订单状态用 TINYINT 加注释比在代码里存中文“已出票”更便于扩展状态机。订单表的主键用自增 ID 没有错但如果订单号直接暴露给用户后面做退票对账时容易暴露业务量常见做法是加一个 order_no 业务唯一键自增 ID 只做内部关联。4. JSP 机票项目常见问题排查zip 解压、驱动冲突和连接池耗尽的 5 个典型坑4.1 zip 解压中断或中文乱码先修复压缩包再谈代码现象把“jsp 机票预订系统源代码.zip”解压到一半工具提示“无法作为 ZIP 包打开”或者直接报 invalid zip archive: could not find eocd就算解压出来了某些文件夹名是乱码。原因基本是两个一是文件在传输过程中被截断末尾的 End of Central Directory 记录丢失ZIP 工具找不到目录结束标记二是压缩包里的文件名是旧式 GBK 编码现代解压工具默认按 UTF-8 解码于是中文名乱码。解决先用命令行校验压缩包完整性zip -T source.zip如果校验失败优先重新下载源文件。修复不是总能成功但可以试试把文件重新拼接zip -FF source.zip --out source_fixed.zipzip -FF 会尽可能找回局部损坏的数据适合压缩包只有尾部损坏的情况。解压出来后的中文乱码通常可以用支持编码选择的解压工具重新解压指定 GBK 解码。不要在网上找“zip 密码移除”类工具去碰加密压缩包加密的包直接找作者要密码最实际暴力破解的时间和精力远超项目本身价值。4.2 MySQL 8 与老驱动冲突ClassNotFound 和 SSL 握手失败现象Tomcat 启动时报java.lang.ClassNotFoundException: com.mysql.jdbc.Driver或者访问登录页时控制台刷出 Communications link failure下面跟着 SSL connection error。原因MySQL 8.0 默认认证插件是 caching_sha2_password老版本 mysql-connector-java 不支持而 8.x 驱动里旧驱动类的加载路径已经变了。你以为是代码问题其实是依赖和数据库版本错配。解决把 WEB-INF/lib 下的数据库驱动替换成与 MySQL 主版本匹配的新驱动同时把 db.properties 里的驱动类改成 com.mysql.cj.jdbc.Driver。连接串上补齐参数jdbc.urljdbc:mysql://localhost:3306/air?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue 是 MySQL 8 在使用 caching_sha2_password 认证、且连接未开启 SSL 时必需的参数不加就会看到 Public Key Retrieval is not allowed。这里的 useSSLfalse 只适合本地开发环境生产环境如果网络不隔离应该优先启用 SSL不能照抄开发配置。4.3 请求和响应中文乱码四个环节必须同一个字符集现象登录成功后页面上的中文提示变成“???”或者表单提交到后台后SQL 里查出来的是“鏉?”数据库里存的也是乱码。原因从浏览器发请求到 JSP 页面渲染结果中间经过 Tomcat 解码、JSP 源码编译、JDBC 传输、数据库存储四个环节只要有一个环节不是 UTF-8乱码就会出现。四个环节没对齐等于给自己埋雷。解决统一改成 UTF-8。首选在 web.xml 里加编码过滤器filter filter-nameencodingFilter/filter-name filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-nameencodingFilter/filter-name url-pattern/*/url-pattern /filter-mappingSetCharacterEncodingFilter 是 Tomcat 自带类war 包里不需要额外引其他 jar。如果项目里没有 web.xml自己写一个 Filter 原理相同在 doFilter 里调用 request.setCharacterEncoding(UTF-8)并把 response 的 contentType 设成 text/html;charsetUTF-8。剩下三个环节对照检查JSP 文件第一行的 pageEncoding 改成 UTF-8Tomcat 的 server.xml 里给 Connector 加上 URIEncodingUTF-8数据库表字符集用 utf8mb4URL 里带 characterEncodingutf8。这四个位置都到位乱码基本绝迹。4.4 页面卡死数据库报 Too many connections连接泄漏的排查现象系统刚启动时一切正常用过十几分钟后页面逐渐变慢最终卡死数据库错误日志里出现 Too many connections。原因老代码用 DriverManager.getConnection 获取连接使用后没有在 finally 里关闭或者页面执行抛异常直接跳到错误页Connection 对象成了永远无法回收的孤儿连接。MySQL 默认最大连接数不算高只要有一个连接没释放几十次访问就能把连接数耗尽。解决所有获取连接的地方改成 try-with-resources 写法try (Connection conn getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, username); try (ResultSet rs ps.executeQuery()) { if (rs.next()) { return mapUser(rs); } } } catch (SQLException e) { LOGGER.error(query user failed, e); }连接对象声明在 try 圆括号里代码块结束时 Java 会自动调用 close即使中途抛异常也会关闭。ResultSet 要单独放进内层 try因为有些老驱动在 Connection 关闭后 ResultSet 会报错。如果项目里用了 C3P0、Druid 这类连接池查一下最大连接数配置设得太小高并发下一样会等连接超时。连接池里调用 close 只是归还连接而不是真正断开不要在 close 之后还去读 rs这是新手经常误解也是连接池场景下最常见的连接错乱来源。4.5 JSP 编译报错和 500JAVA_HOME 与 Tomcat 版本不匹配现象Tomcat 能启动但打开任意 JSP 页面都是 HTTP 500日志里有明显一行“Unable to compile class for JSP”往下是 JSP 文件名字和行号个别时候能看到 PWC 开头的错误码。原因包括JSP 里的 Java 代码语法有问题引用了 WEB-INF/lib 里不存在的类Tomcat 运行时用的 JRE 和 JAVA_HOME 配置不一致导致编译版本冲突。解决先定位 Tomcat 的 work 目录。Tomcat 会把每个 JSP 翻译成 _jsp.java 再编译文件路径一般是 work/Catalina/localhost/项目名/org/apache/jsp/。打开对应 _jsp.java编译错误信息里的行号指向的是翻译后的文件对照原 JSP 就能找到真正出错的代码。如果日志提示 JSP 里找不到某个类优先检查 WEB-INF/lib 和 WEB-INF/classes 下是不是真的有这个类而不是看 IDE 的构建路径里有没有。最后确认 echo $JAVA_HOME 和 java -version 是否指向同一个 JDK。Tomcat 用的是 JAVA_HOME不是 PATH 里的 java。这两个不一致的时候在 IDE 里编译正常部署到 Tomcat 就可能出现奇怪的版本错误这也是 JSP 项目特有的“环境病”。5. 值不值得继续用JSP 机票项目的三个判断信号和一条低成本改造路径5.1 三个信号判断老系统能不能直接用JSP 机票系统能不能直接拿来用看三个信号就够。信号一是权限控制是否真的存在。打开 web.xml 和后台 JSP很多课程设计只在管理员页面里判断 session 变量是不是 admin用户把 URL 改成 admin.jsp 就能绕过。这种权限形同虚设。修法是加一个 Filter 做角色校验或者至少在 Servlet 里统一判断当前登录用户角色。信号二是 DAO 里有没有 SQL 注入。搜索代码里的字符串拼接如果看到where username username 这种写法所有用户输入都能破坏查询条件。修法不复杂把拼接改成 PreparedStatement参数用 setString 绑定LIKE 查询里的百分号要用参数传递而不是拼进 SQL。信号三是 JSP 页面里是不是直接写了业务逻辑。打开 index.jsp 或 flight_list.jsp如果看到大段% %代码在循环拼表格、在查数据库说明业务逻辑已经侵入视图。这种系统改一个需求往往要同时改 JSP、Servlet、DAO 三处越往后维护成本越高。如果三个信号一个都没中系统还能继续用中了两个以上建议把它当学习或验收演示用不要直接上线。判断逻辑很简单这类项目数据量不大、并发也不高瓶颈从来不是性能而是代码混乱带来的改动风险和安全隐患。另外源代码管理习惯往往也很随意没有依赖锁文件升级一个驱动要靠手动拷贝 jar 包这也是改造前要付出的隐形成本。5.2 保留 DAO、替换视图最低成本的改造顺序如果确定要改造不要一上来就规划 Spring Boot 重写。那种做法会把一个两周能完成的改造拖成两个月而且老系统的行为边界根本没人清楚。我一般建议按“保留 DAO、替换视图”三步走。第一步把 Servlet 改成 JSON 接口。登录成功时不再转发到 JSP而是返回一段 JSONresp.setContentType(application/json;charsetUTF-8); resp.getWriter().write({\code\:200,\message\:\ok\,\data\: json });前端页面改成原生的 fetch 请求fetch(FlightListServlet, { method: POST, body: new URLSearchParams({ pageNo: 1, pageSize: 10 }) }) .then(res res.json()) .then(data renderFlightTable(data)) .catch(err toast(err.message));URLSearchParams 在提交表单数据时比手动拼接字符串更安全页面里如果前后端字段名不一致可以在这里统一做映射。第二步把页面里的 JSP 逻辑搬出来。以前 JSP 直接用% %遍历数据改成 HTML 模板渲染数据由接口返回。这一步可以保留老 DAO 和表结构不动改动集中在 Servlet 和 JSP 之间。第三步把资源管理升级一下。老代码里 DriverManager.getConnection 每次新建连接改成 Druid 或 HikariCP 连接池初始化参数就关注三个initialSize、maxActive、maxWait。改完以后要跑一段长时间场景确认连接不再泄漏。改造的边界要清楚DAO 的方法签名可以继续复用但分页、权限、参数校验这些 JSP 时代缺失的逻辑不会因为换前端自动变出来。改完接口层后要逐页重新验证权限尤其是管理后台的入口。反过来如果表结构已经乱到查一条订单要 join 五张表页面和 Servlet 职责彻底混在一起重建一个简化模块往往比重构更快。这种判断很主观但工程里“值不值得继续用”比“怎么改”更值得先想清楚。改造前先给整个项目打一个 war 包备份这是唯一的后悔药。6. 让航班列表不再卡死把 ResultSet 全表查询改成 LIMIT/OFFSET 分页的一个技巧课程设计的航班表通常只有几十行所以老代码习惯直接SELECT * FROM flight然后在 JSP 里循环输出。一旦数据量到了几万行页面响应时间会明显拉长。最直接的改法是给列表查询加分页SELECT * FROM flight ORDER BY takeoff_time LIMIT 10 OFFSET 0;OFFSET 的算法是(pageNo - 1) * pageSize。还要一个总数查询来计算分页按钮SELECT COUNT(*) FROM flight;DAO 里对应两个方法countByCondition() 和 pageByCondition(pageNo, pageSize)。SQL 里的 ORDER BY 字段建议有索引否则深翻页时数据库还要做排序。机票业务量不大真正先变慢的一般是后台订单列表。如果只查未退票订单在 status 和 flight_no 上各加一个普通索引就够了。我最早接手类似老系统时图省事把订单表一次全查出来在 JSP 里拼表格。后来订单量从几千行涨到几万行一次页面打开要 4 秒Tomcat 频繁出现长时间 GC。最后改成分页查询加索引才消停。这类改造别急着上缓存和消息队列先把最粗暴的 SQL 和连接泄漏修掉收益往往最大。希望帮到你。本文还有配套的精品资源点击获取