企业官网建设流程全解析

简介：JSP机票预订系统源代码是一套基于Java Web的完整项目，面向初学JSP/Java的开发者及需要课程设计参考的学生，模拟在线机票搜索、预订、乘客信息填写、订单确认等业务环节。压缩包共1644个文件，大小约38.59MB，除JSP页面与Servlet、DAO等Java源码外，还包含jar依赖库、js/css前端资源，以及gif/png/jpg/swf图片动画和db/sql数据库脚本，目录结构清晰，目前已有155人学习。通过研读可实现用户登录认证、表单验证、会话管理、数据库增删改查等典型功能，体会MVC分层与项目组织方式，也能从WEB-INF、jsp、css、js等目录划分了解标准Web工程的搭建思路；这套源码还附带数据库初始化脚本，可快速重建航班和订单数据，方便直接运行体验，适合作为Java Web入门实践参考，也可在此基础上二次开发成毕业设计或商城类项目。

1. 拿到「jsp 机票预订系统源代码.zip」之后：先搞清楚你手里是什么

如果你最近在找毕设或课设素材，“jsp 机票预订系统源代码”这个压缩包应该不陌生。解压之后是一堆 .jsp 页面、几个 servlet、一个 sql 脚本，名字听着像现成的作业，但真正能把它跑起来的人不到一半。这个标题指向的是一个典型的 Java Web 课程设计项目：前台模拟航班查询、在线订票，后台管理航班与订单，技术栈停留在 JSP + Servlet + JavaBean 时代，不碰 Spring。它解决的核心问题，是让初学者在没有任何框架的干扰下，把一次完整请求从 jsp 页面走到 servlet、再到数据库、再返回到页面展示，完整闭环走一遍。适合两类人：一类是要交课程设计的大二大三学生，另一类是刚接触 Java Web、想绕开框架看底层请求流转的开发者。它的价值不在代码有多强，而在于它是少数能一次看懂“请求到底怎么走”的完整样例。

2. 把源码跑起来：JDK / Tomcat / MySQL 的版本搭配与最小部署步骤

网上这类源码包多数是 2015 年前后的产物，写代码时用的还是 Eclipse + Tomcat 7，数据库脚本也是按 MySQL 5.x 写的。你如果直接用最新的 JDK 17 + Tomcat 10 + MySQL 8，大概率会在环境阶段就翻车，代码本身反而是次要问题。

这个版本组合不是玄学。JSP 技术栈对应的是 javax.servlet 时代，Tomcat 8/9 还认 javax 命名空间，Tomcat 10 强制改成 jakarta，老源码里的 import 全部失效。MySQL 5.7 对老建表语句兼容最好，很多 sql 脚本里没有指定 utf8mb4，在 5.7 下默认也能跑，到 8.x 就容易出现字符集告警。所以第一步先把环境锚定在老版本，跑通之后再考虑往新版本迁。

2.1 先从解压目录判断项目形态：src 和 WebRoot 是两条命脉

解压之后不要急着打开 IDE，先看根目录。老 JSP 项目通常有两种形态：一种是 Eclipse 的动态 Web 项目结构，下有 src 和 WebRoot（或 WebContent）两个目录；另一种是 war 包装的散文件，顶层直接是 jsp 和 WEB-INF。判断标准很简单：有没有 src 文件夹。有 src，说明源码完整，可以继续；只有编译后的 classes，说明是个半残包，后续改代码会非常痛苦。

确认 src 存在后，再看 WEB-INF 下有没有 lib 文件夹。很多源码发布时会把 jar 包删掉只留代码，导致你导入后一堆红叉。常见做法是去 Tomcat 的 lib 目录补齐 servlet-api.jar，再去 MySQL 官网下载对应版本的 JDBC 驱动。这两样是最基础的两个依赖，先确认它们在不至于后面被 ClassNotFoundException 反复折磨。

2.2 加载项目并启动 Tomcat：IDEA 里最容易漏掉 lib 依赖

以 IDEA 为例，导入步骤是这样的：File → New → Project from Existing Sources，选中解压目录，选择 Eclipse 项目类型导入。导入后先别急着配 Tomcat，先把输出目录和依赖理顺。老项目在 IDEA 里最常见的坑是：src 编译后生成的 classes 没有进 WEB-INF/classes，lib 里的 jar 没有进 WEB-INF/lib，导致启动后找不到驱动或者访问页面报 404。

# 检查编译输出位置（IDEA 的 out 目录结构） # 正确结构要求： # out/artifacts/<项目名>/WEB-INF/classes ← 编译后的 .class 文件 # out/artifacts/<项目名>/WEB-INF/lib ← 项目依赖的 jar 包 # out/artifacts/<项目名>/*.jsp ← 页面文件

逻辑说明：IDEA 生成 Artifact 时默认只打源码和资源文件，外部导入的 lib 文件夹不会自动包进去，所以每次构建完都要检查一下这两个目录。参数说明：WEB-INF/classes 决定了 servlet 能不能被 Tomcat 找到，WEB-INF/lib 决定了 JDBC 驱动和 JSTL 标签库能不能加载。这两个目录缺一个，启动时不会立刻报错，而是访问到某个页面或某个接口时才炸，排查成本很高。

2.3 初始化数据库：一条 source 命令把航班表和订单表建起来

老项目的 sql 脚本通常是一个包含建库、建表、插入测试数据的大文件，命名一般是 flight.sql 或 airline.sql。用命令行导入最稳，不要在 Navicat 里直接双击运行超大脚本，容易中途中断。

mysql -uroot -p # 进入 MySQL 后执行： source /your/path/flight.sql; # 如果脚本里没有建库语句，先手动建库再指定库导入： create database airline default charset utf8mb4; use airline; source /your/path/flight.sql;

逻辑说明：source 是按行读取执行，能比较清晰看到哪条语句报错。脚本开头一般会 create database 或 use 某个库，你只需要保证执行用户有权限。参数说明：密码、端口、字符集三个地方要提前确认。如果脚本里写了 use airline 而你本地没有这个库，MySQL 会报 ERROR 1049，这时候手动建库再导入即可。导入成功后重点检查三张表：用户表、航班表、订单表，老项目字段命名常用拼音缩写（比如 hbxx、ddxx），这是那个年代的习惯，不要被吓到。

3. 读懂代码结构：JSP + Servlet + JavaBean 怎么支撑一次订票请求

环境跑通之后，大多数人会陷入下一个迷茫：文件这么多，先看哪个？这个阶段的目标不是逐行读完，而是把“黑匣子”打开看明白一次请求的流转路径。登录、查航班、下单、后台管理，四条业务线各走一遍读代码，基本就能摸清整套系统的脉搏。

3.1 从登录到下单：一次请求的完整链路

热门搜索里经常出现的“按照 jsp modeled2 思想实现用户注册功能”，说的就是这套标准流程。所谓 Model 2，核心规矩是：jsp 不再直接连数据库，而是把请求参数交给 servlet，servlet 调用 JavaBean 处理业务，再把结果放到 request 或 session 中，最后 forward 回 jsp 渲染页面。你在源码里看到的所有代码，都是这个思想的具体实现。

登录请求的链路是这样走的：浏览器提交 login.jsp 里的表单，Tomcat 根据 web.xml 或 @WebServlet 注解找到 LoginServlet，servlet 从 request 里拿 username 和 password，调 UserDao 查数据库，查到了就把用户信息塞进 session，然后 forward 到用户个人信息展示页面；查不到就往 request 里放一个 error 属性，调回 login.jsp 显示“用户名或密码错误”。整个过程没有跳转 URL，地址栏始终是 login.jsp，这就是 forward 和重定向的区别所在。

3.2 核心代码片段：LoginServlet 与登录状态如何写入 session

@WebServlet("/login") public class LoginServlet extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // 统一设置请求编码，防止中文用户名乱码 request.setCharacterEncoding("UTF-8"); String username = request.getParameter("username"); String password = request.getParameter("password"); UserDao dao = new UserDao(); User user = dao.findByUsernameAndPassword(username, password); if (user != null) { HttpSession session = request.getSession(); // 只存关键字段，不存整个对象，降低 session 体积 session.setAttribute("userId", user.getId()); session.setAttribute("username", user.getUsername()); // 登录成功跳转到个人信息展示页面 request.getRequestDispatcher("userInfo.jsp").forward(request, response); } else { request.setAttribute("error", "用户名或密码错误"); request.getRequestDispatcher("login.jsp").forward(request, response); } } }

逻辑说明：这个类继承 HttpServlet，重写 doPost 处理表单提交。请求进来先设置字符编码，原因见后面的避坑章。UserDao 直接操作 JDBC，findByUsernameAndPassword 方法内部拼接 SQL 查询用户表，返回 null 或 User 对象。登录成功时把 userId 和 username 放进 session，后续所有页面都能通过 session.getAttribute 拿到登录人信息。失败时用 request.setAttribute 存放错误信息，再 forward 回登录页。

这里要特别说明 forward 和重定向的选择。老源码里两个写法都有，但语义完全不同：forward 是服务器内部的转发，URL 不变，request 里存的东西还能读到，适合登录失败回显错误；重定向是浏览器重新发一次请求，URL 会变，request 里的属性全部丢失，适合登录成功后跳转到首页。很多新手把登录失败也写成重定向，结果错误信息永远显示不出来，排查半天发现是数据在跳转时被丢光了。

3.3 航班查询与下单：状态和条件怎么在 jsp 表单之间传递

查航班是这套系统里最有代表性的业务。查询页面一般是 queryFlight.jsp，上面有几个输入框：出发城市、到达城市、出发日期，点击查询后提交给 FindFlightServlet，servlet 调 FlightDao 查数据库，结果 List 放到 request 里，forward 到航班列表页面循环输出。注意这里的分页通常是假分页，或者用 LIMIT 做简单分页，参数 pageNo 和 pageSize 由页面上的隐藏字段传递。

public List<Flight> findFlights(String from, String to, int pageNo, int pageSize) { String sql = "SELECT * FROM flight WHERE from_city=? AND to_city=? LIMIT ?,?"; // 参数绑定，避免字符串拼接引发的 SQL 注入 try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, from); ps.setString(2, to); ps.setInt(3, (pageNo - 1) * pageSize); ps.setInt(4, pageSize); ResultSet rs = ps.executeQuery(); // 循环封装 Flight 对象到 List } catch (Exception e) { e.printStackTrace(); } return list; }

逻辑说明：PreparedStatement 的参数绑定是这里最值得学习的写法，比字符串拼接安全一个量级。LIMIT 的两个参数，第一个是偏移量，等于（当前页 - 1）× 每页条数，第二个是每页条数。页码从页面 request.getParameter("pageNo") 拿，老代码经常忘记 parseInt 时做非空判断，导致第一页就抛 NumberFormatException。

下单环节则更简单粗暴：订单提交页把一个隐藏的 flightId 和当前登录用户的 userId 提交到 AddOrderServlet，servlet 往订单表 insert 一条记录，状态字段默认填“已预订”。很多老源码没有扣减库存的逻辑，也不做重复下单校验，这是业务层面的缺陷，但作为课设演示，它能完整跑通一个状态流转，反而是你向答辩老师解释“数据表状态设计”的切入点。

4. 落地前必调的 4 个参数：连接串、分页、字符集与登录校验

环境跑通、代码读顺之后，你想把它真正用起来，必须处理四个参数类问题。这些问题不在代码逻辑里，而在配置和边界处理里，但它们决定了系统在真实场景下能不能稳定工作。

4.1 数据库连接参数：jdbc.properties 里容易忽略的三行

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/airline?useUnicode=true&characterEncoding=UTF-8 jdbc.username=root jdbc.password=123456

逻辑说明：老项目一般把连接配置放在 src 下的 jdbc.properties，由 DBUtil 静态代码块加载。driver 是驱动类名，url 里的 useUnicode 和 characterEncoding 决定了中文能否正确写入数据库，username 和 password 要和本机 MySQL 一致。参数说明：如果你用的是 MySQL 8.x 驱动，driver 要写成 com.mysql.cj.jdbc.Driver，url 末尾还要加 serverTimezone=Asia/Shanghai，否则会报时区错误。这个差别单独在避坑章展开。很多源码里没有这个文件，而是把连接信息直接写死在 DB.java 里，这也不影响运行，只是换环境时改一行配置要重新编译。

4.2 分页参数：pageNo 为空和查询条件丢失是两个必踩的坑

老 JSP 系统的分页几乎都是自己写的 PageBean，页面底部有“上一页、下一页”链接，链接里带 pageNo 参数。最常见的 bug 是：翻到第二页时，出发城市、到达城市的筛选条件全没了，列表变成全量数据。原因很简单——下一页的链接只拼了 pageNo，没拼 from 和 to 这两个查询条件。

<%-- 正确做法：翻页链接里带上查询条件 --%> <a href="FindFlightServlet?from=<%=from%>&to=<%=to%>&pageNo=<%=pageNo+1%>">下一页</a>

逻辑说明：servlet 每次接收请求都要从 request 里取一遍 from 和 to，翻页链接如果不回传，servlet 取到的就是 null，查询条件自然失效。参数说明：pageNo 还要做空值兜底，第一次访问没有 pageNo 参数时默认取 1，否则 Integer.parseInt(null) 直接抛异常。这种小问题在答辩演示时很容易暴露，你只需要在传参处多写一个三元判断就能避免。

4.3 字符集：pageEncoding、POST 编码、连接器编码三处对齐

中文乱码是 JSP 老项目里的老大难。常见的乱码有两类：页面显示成乱码，和数据库里存成乱码。排查思路不是改一处，而是把三处对齐：

第一处是 jsp 文件头部的 pageEncoding，它控制 jsp 文件本身以什么编码读取和编译；第二处是请求阶段的编码，POST 提交的数据需要在 servlet 里调用 request.setCharacterEncoding；第三处是 Tomcat 连接器的 URIEncoding，影响 GET 请求和 URL 参数的中文解析。老源码经常只设置了第一处，漏了后两处，于是出现“页面对、提交乱、存储乱”的连环问题。改法很简单，在三处都统一写上 UTF-8 即可，重点是不漏项。

4.4 登录校验：一个 filter 挡住未登录用户访问后台

很多老源码的后台管理页面没有权限校验，访问 admin 目录下的 jsp 直接就能打开，或者只在每个 servlet 里重复检查 session。前一种太危险，后一种代码冗余严重。常见做法是加一个 filter，拦住 /admin/ 下的所有请求：

@WebFilter("/admin/*") public class LoginFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpSession session = request.getSession(false); // 没有登录就去登录页，不放行 if (session == null || session.getAttribute("userId") == null) { request.getRequestDispatcher("../login.jsp").forward(request, resp); return; } // 已登录就继续执行后续的 servlet 或 jsp chain.doFilter(req, resp); } }

逻辑说明：@WebFilter 注解声明拦截路径，/admin/* 表示这个目录下所有资源的访问都先进 filter。session 为空或 userId 不存在，说明没登录，直接转发到登录页。注意 request.getSession(false) 里的 false，表示如果当前没有 session 就返回 null 而不是新创建一个，避免给每个游客都生成无意义的 session。参数说明：filter 是这套系统里最值得加的一个功能，老代码往往在每个后台 servlet 里重复写登录判断，用 filter 统一处理一次能减少大量重复代码，面试时也能讲出“统一鉴权”的概念。

5. 避坑：老 JSP 项目跑不起来的 5 个高频现场与解法

这一节把前四章埋下的坑集中收口，每一条都是真实运行中反复出现的现场，按“现象 → 原因 → 解决”的顺序写，方便你照着排查。

5.1 Tomcat 10 直接跑老项目：一启动就 500，javax 去哪了

现象：用最新版 Tomcat 10 启动老 JSP 项目，访问任何 servlet 都返回 500，控制台报 java.lang.NoClassDefFoundError: javax/servlet/ServletException。原因：Tomcat 10 在 Java EE 迁移时把 javax.servlet 整个命名空间改成了 jakarta.servlet，老项目的 import javax.servlet.http.HttpServlet 全部失效。解决：最省事是换成 Tomcat 9，源码一个字都不用改；如果坚持用 Tomcat 10，需要把代码里所有 javax.servlet 替换成 jakarta.servlet，同时换掉对应的 jar 包依赖。对新手只推荐前者，改动最小，见效最快。

5.2 MySQL 8.x 连不上：驱动类名和时间戳参数是两处差异

现象：启动报 ClassNotFoundException: com.mysql.jdbc.Driver，或者报 Communications link failure 连接超时。原因：MySQL 8.x 的官方驱动把类名从 com.mysql.jdbc.Driver 改成了 com.mysql.cj.jdbc.Driver，且新版驱动要求连接串里带 serverTimezone 参数。解决：去下载 mysql-connector-java 8.x 的 jar 替换旧驱动，然后改 jdbc.properties：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/airline?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai

逻辑说明：driver 是驱动类入口，类名变了就必须跟着变，否则 JVM 找不到类。serverTimezone 是因为新版驱动默认要求明确时区，不写会报 The server time zone value 的运行时异常。参数说明：如果你的数据库服务器不在国内，Asia/Shanghai 要换成对应时区，国内环境用这个值即可。

5.3 中文乱码：三种表现分别对应哪一处配置

现象一：页面本身显示乱码，通常是 jsp 文件头部的 pageEncoding 写成了 ISO-8859-1 或没写，改成 UTF-8 即可。现象二：页面显示正常，但提交到服务器后保存在数据库里变成问号或乱码，这是 servlet 接收参数前没调 request.setCharacterEncoding("UTF-8")，或者连接串里的 characterEncoding 没设。现象三：GET 请求的 URL 参数乱码，需要在 Tomcat 的 server.xml 中给 Connector 加一个属性 URIEncoding="UTF-8"。这三处不是一个问题，必须逐个核对，很多项目改了一处发现还乱，就以为方法没用，其实是三处只改了两处。

5.4 两个安全现场：SQL 注入和备份文件落进 web 目录

现象：在航班搜索框输入 1' or '1'='1，结果返回了全部航班列表；更离谱的是，有人能通过浏览器直接下载服务器上的 backup.zip 备份文件。原因：前者是老代码用了字符串拼接 SQL，用户输入被当成 SQL 语法执行了；后者是把备份文件随手放进了 web 目录下的某个文件夹，Tomcat 对 web 目录下的静态文件默认就能直接访问。解决：SQL 拼接统一改成 PreparedStatement 参数绑定；备份文件要么放 webapps 目录之外，要么给敏感目录加访问控制。这条在答辩时被老师问到的概率极高，能主动说出来反而是加分项。

5.5 ClassNotFoundException 与 lib 目录：导入时丢 jar 的老问题

现象：代码从 Eclipse 导入 IDEA 后，启动报 ClassNotFoundException: com.mysql.jdbc.Driver，但项目目录里明明能看到 mysql-connector 的 jar 包。原因：IDEA 的 Artifact 打包配置里，WEB-INF/lib 没有被勾选，编译发布后 jar 根本不在运行环境里。解决：Project Structure → Artifacts → 选中项目 → 在 Available Elements 里把 lib 文件夹右键选择 Put into WEB-INF/lib，然后重新 Build Artifacts。判断是否成功的标准是 out/artifacts/ 目录下真的生成了 WEB-INF/lib 文件夹，并且里面躺着你需要的 jar 包。每次换电脑换环境，第一件事先检查这个。

6. 这份源码值不值得投入：先跑通，再往“能讲出来”改

先给结论：值，但投入方式取决于你的目标。如果你的目标是一周内交一份能现场演示的课程设计，这个包基本够用。你现在只需要做到三件事：能启动、能讲清登录和订票两条链路、能指出数据库里三张核心表的关联关系。做到这一步，答辩时老师不会为难你。如果你的目标是拿它去面试讲项目，那就不能停留在“能跑”，因为现在团队在用的基本都是 Spring Boot 方向，面试官听到“我做过 JSP 项目”大概率会追问一句：你后来有没有往 Spring Boot 迁过？

我的建议是往三个方向做改造，每个方向都对应一个通用的工程能力。第一步是把 jsp 页面里直接写的 Java 代码拆到 dao 层，目标是页面里看不到 import java.sql；第二步是把所有字符串拼接的 SQL 换成 PreparedStatement，顺手把 SQL 注入的坑填掉；第三步是加一个登录 filter，统一做鉴权，替代每个页面重复检查 session 的写法。这三步做完，你手里这份源码就从“能跑的课设”变成了“能讲出设计亮点的项目”。

// 改造前：jsp 页面里直接拼 SQL 访问数据库 // <% String sql = "select * from flight where from_city='" + request.getParameter("from") + "'"; %> // 改造后：页面只负责取值和展示 // <%= flightDao.countByCity(from, to) %>

我第一份课程设计也是这么改过来的。当时答辩老师翻了几页代码，指着一处写在 jsp 里的查询语句问：这个页面的职责是什么？我答不上来。那之后我养成了一个习惯，拿到任何源码，先搜 import java.sql 和 out.print，看业务逻辑到底埋在哪里。现在你手里这份 jsp 机票预订系统的源代码，恰好就是练习“看清代码边界”的最佳样本——它足够老、足够小，所有问题都摊在明面上，改一遍比看十篇框架教程都管用。希望帮到你。

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