企业官网建设流程全解析

又到了一年一度的毕业设计季节。每年这时候，后台总会收到大量关于“传统Java Web项目还值不值得做”的私信，而jsp出租公司管理系统这个选题恰好是其中被问得最多的一个——它既是计算机毕业设计库里的老面孔，又承载着很多初学者对Java Web的第一次认知。这篇文章我从一个做过大量类似项目、也帮人改过不少烂代码的从业者视角，把这套系统的选型逻辑、技术原理、核心实现、部署细节和答辩要点全部拆开讲透。

我知道很多人看到JSP第一反应是“这技术不是过时了吗”。但过时和没用是两回事，毕业设计这件事的核心逻辑从来不是追最新框架，而是用你最能驾驭的技术，把业务逻辑完整、清晰地表达出来。JSP系项目天然具备这种优势：你不需要在Spring Boot的自动配置、依赖注入和AOP里绕圈子，一条请求从浏览器到JSP页面再到数据库，每个环节都赤裸裸地摆在面前。这种“看得见摸得着”的特性，恰好是答辩时你能讲清楚、讲深入的最大资本。

下面我按照毕业设计从选题到答辩的完整链路，把这套系统方方面面给你捋明白。

1. 这个选题还有没有价值：JSP毕设的真实处境

1.1 为什么JSP至今仍是毕业设计的高频选项

每年毕业设计选题库刷新一轮又一轮，但JSP系的管理系统始终占据半壁江山。我接触过不少同学，他们看到选题列表时会犹豫——周围人都在做Spring Boot，自己拿个JSP题目会不会显得很没水平？

真实情况恰恰相反。毕业设计的评分标准里，业务完整性和答辩表达能力往往比技术栈新旧更关键。JSP项目在这两点上有天然优势：

• 学校课程通常以Java Web为主线，课堂上教的、教材上写的就是JSP+Servlet+JDBC这套组合，用熟悉的技术做设计，翻车概率最低。
• 一个JSP项目的请求流程可以画成极清晰的链路图——浏览器发起请求、Servlet接收并处理、调用DAO访问数据库、结果渲染回JSP页面。这种清晰的链路在答辩时非常容易讲明白。

1.2 JSP和Spring Boot：到底该怎么选

我不止一次被问到这个问题。直接给结论：

• 如果你对Java有一定基础，且论文需要体现完整的MVC分层思想，选JSP完全够用。JSP项目在结构上天然就是MVC——JSP对应视图层，Servlet对应控制层，JavaBean/DAO对应模型层，每一层该干什么清清楚楚。
• 如果你已经熟练掌握了Spring Boot，那也不建议非选JSP题目硬做。你大可选Spring Boot+Vue的题目，然后自己实现一个现代版的前后端分离系统。
• 最忌讳的是选了个JSP题目，却非要用Spring Boot重新实现一遍。最后两边都没学透，答辩时连“你们为什么不用JSP”这种基础问题都答不好。

我做毕业设计辅导时反复强调：毕设的核心永远是“能跑+能讲”，不是“技术多新”。JSP从来不是加分项，但如果你把它做成一个逻辑完整、界面规整、功能闭环的项目，它就一定不是减分项。

1.3 一个老开发对JSP的重新认识

说了这么多，我想从行业视角多说一句。现在企业里JSP确实不再是主流——前后端分离后，后端提供接口、前端负责渲染已经是标配。但JSP本身的“服务端渲染”思想并没有过时，只是换了个样子继续存在，比如模板引擎、SSR框架等等。你通过JSP学会的session管理、请求转发、过滤器链、数据库连接池这些东西，到了任何技术栈都是通用的。别把JSP当成终点，而要把它当成理解Java Web底层运行机制的起点。这也是我依然愿意给人写JSP毕设项目文章的原因——它帮你打的地基，比框架帮你省的那些事值钱得多。

2. 出租公司管理系统需求拆解与数据库设计

2.1 系统到底要做哪些功能

出租公司管理系统，听起来业务复杂，但放到毕业设计的尺度上，核心就是把“车辆出租”这条线走通。我在设计这类系统时习惯用角色反推法——先盘清楚系统里有哪些角色，每个角色需要做什么事，然后把功能清单拉出来。

出租公司管理系统通常涉及三类角色（有的系统会把客户和员工合并，但我建议分开，功能边界更清晰）：

功能模块上，我建议做好这几块就足够支撑一篇完整的毕业论文：

1. 登录与权限管理：三类角色共用登录入口，登录后根据角色分配不同操作权限。
2. 车辆信息管理：新增车辆、编辑信息、上下架（设置为“可出租/已出租/维修中”）、按条件搜索车辆。
3. 客户信息管理：客户资料增删改查，身份证/驾驶证信息登记。
4. 订单管理：这是全系统的业务核心。客户选择车辆、提交租车时间段、员工审核通过、出车、归还结算、订单关闭，全流程状态机管理。
5. 统计报表：按月统计出租订单量、营收、车辆利用率，这是论文里最能体现“系统价值”的模块，也是答辩加分项。
6. 系统管理：操作员账号管理、基础参数设置（如租金计算规则、超时费用等）。

2.2 数据库表结构设计思路

数据库设计是整个系统里最兵家必争之地。很多同学喜欢一上来就建表，结果后面加字段加到哭。我的习惯是先画业务流转图，再依据流转中的每个实体建表。

这套系统我建议至少设计以下7张表：

• t_user（用户表）：用户ID、用户名、密码、真实姓名、角色、联系电话、创建时间。
• t_employee（员工表）：员工ID、所属用户ID、工号、职位、入职时间。如果用户表已经覆盖了员工的信息，这张表可以省，但从业务完整性上建议保留。
• t_car（车辆表）：车辆ID、车牌号、品牌、型号、颜色、座位数、日租金、押金、车辆状态（0-可出租 1-已出租 2-维修中 3-停用）、购买日期、车辆照片路径。
• t_customer（客户表）：客户ID、姓名、性别、身份证号、驾驶证号、联系电话、地址、会员等级、创建时间。
• t_order（订单表）：订单编号、关联车辆ID、关联客户ID、关联员工ID（经办人）、租车开始时间、计划还车时间、实际还车时间、租车天数、日租金快照、总金额、实际金额、押金、订单状态、备注。
• t_maintenance（维修表）：维修ID、关联车辆ID、维修日期、维修项目、费用、维修厂、备注。
• t_statistics（月度统计表）：如果不想用SQL现场聚合，可以用统计表做结果缓存。毕业设计直接写SQL聚合即可，这张表可选。

2.3 表关系与订单状态流转

表关系相对固定：车辆和订单是一对多，客户和订单是一对多，员工和订单是一对多（经办人）。核心的难点在订单状态设计上，这也是答辩时老师最爱深挖的地方。

我建议订单状态设计成如下状态机：

• 0-待审核：客户提交订单后等待员工审核。
• 1-已确认/待取车：员工审核通过，车辆被锁定为“已出租”。
• 2-出租中：客户已取车，车辆在客户手中。
• 3-待归还：即将到期或已到期的订单（这个状态可以用定时任务或手动点击触发）。
• 4-已归还：客户归还车辆，员工登记实际还车时间，计算费用。
• 5-已取消：客户或员工在出车前取消了订单。

状态机设计好之后，代码里的每次操作本质上就是状态迁移加上业务校验。例如：

• 只有“待审核”状态的订单才能被审核；
• 只有“已确认”状态的订单才能出车；
• 只有“出租中”状态的订单才能登记归还；
• 车辆状态和订单状态必须联动，车辆在某个订单处于“已确认”或“出租中”时，不能被分配给其他订单。

把这张状态流转图画清楚，论文里放一页，答辩时照着讲，老师立刻知道你理解了这个系统的业务核心。我在图里特别会标出状态转换的触发条件——这是很多同学最容易忽略的地方。

3. 核心技术原理：JSP请求到底是怎么跑起来的

3.1 JSP的本质：一个被编译成Servlet的HTML

既然标题叫“jsp出租公司管理系统”，JSP本身的技术原理就得吃透。很多人把JSP当成“能写Java代码的HTML”，这话对了一半，但不够准确。

JSP文件在被第一次请求时，会经历这样一个过程：

1. 容器（通常是Tomcat）找到对应的.jsp文件。
2. 容器将JSP解析并翻译成一个Java文件，这个类继承了HttpServlet。
3. 这个生成的Servlet类被编译成.class文件。
4. 容器完成jspInit()的初始化，然后调用_jspService()处理请求。
5. 后续相同页面的请求直接复用编译好的class。

换句话说，JSP天生就是Servlet。你在JSP里写的HTML其实是被out.write()输出出去的，你写的<% ... %>代码块被原封不动地塞进了_jspService()方法里。理解这一点对后面排查问题特别重要。比如页面上的变量报错、内置对象不可用，根源都在这里。

JSP里有九个内置对象，毕设里最常用的四个：

• request：封装客户端请求，用来获取表单参数、请求属性。
• response：封装响应对象，用来重定向、设置响应头。
• session：会话对象，用来保存登录状态、购物车信息等。
• application：全局共享对象，统计在线人数之类的场景会用到。

3.2 为什么要用Tomcat：Servlet容器的作用

Tomcat在JSP项目里不是一个可选项，而是刚需。它做的最核心的一件事是：接收HTTP请求，按照规则找到对应的Servlet或JSP，把请求数据包装好交给代码处理，再取回结果返回给浏览器。

没有Tomcat，JSP文件在浏览器里打开只会被当成纯文本显示，因为浏览器只能解析HTML、CSS和JavaScript，它看不懂JSP标签和Java代码。容器相当于是中间翻译层——把JSP翻译成Java，再把Java编译成可执行的类，最后输出纯HTML给浏览器。

在本地开发时，我强烈建议用IDEA内置的Tomcat集成方式。第一步用IDEA导入项目，第二步选择运行配置，第三步添加本地Tomcat路径。具体步骤后面我单独写一节，这里先把道理讲透：内置集成最大的好处是热部署和实时调试，你改了JSP之后，刷新页面就能看到效果，无需重新启动服务。

3.3 nginx支持JSP吗：这个热搜问题背后的原理

热搜词里有一个很经典的问题——“nginx 支持jsp吗”。很多人搞不懂为什么自己把JSP项目打成war包放进nginx的html目录后，网站根目录打开是一片空白或者直接404。

这里需要先分清楚两个角色。nginx是Web服务器，负责处理静态资源访问，它本身不认识JSP，也无法执行Java代码。如果你让nginx去服务JSP文件，nginx只会把它当普通文本文件原样发出去，或者因为找不到对应的物理文件而报404。

JSP必须交给Servlet容器——也就是Tomcat——来处理。所以标准的生产部署架构是：

• nginx监听80端口，处理静态资源（图片、CSS、JS文件），遇到.jsp结尾的动态请求，通过反向代理把请求转发给Tomcat。
• Tomcat监听8080端口，真正去编译执行JSP，生成HTML返回给nginx，再由nginx返回给客户端。

nginx里配置反向代理的核心代码大概是这样的：

server { listen 80; server_name example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这个配置的含义很简单：所有请求都交给本机8080端口的Tomcat处理。对于毕设答辩环境，你完全不需要上nginx，直接用Tomcat的webapps目录部署war包即可。但如果你能在论文答辩里讲清楚“nginx负责静态资源、Tomcat负责动态请求”的分工逻辑，这会是很大的加分项。

3.4 IDEA新建JSP项目的关键操作

这部分几乎是每个联系我的人都会卡住的起点。我给一个在IDEA里的标准操作路径（以IntelliJ IDEA 2023及以上版本为例）：

创建一个普通的Java项目，而不是直接选择Java Enterprise模板。操作顺序如下：

1. 打开IDEA，选择New Project。
2. 左侧选择Java，右侧选择Maven（如果没有Maven，就选IntelliJ自带构建系统也行，但Maven更方便管理依赖）。
3. 在项目里新建src/main/java和src/main/webapp两个目录。
4. 在webapp目录下新建WEB-INF文件夹，并在里面创建web.xml。
5. 打开Project Structure（快捷键Ctrl+Alt+Shift+S），在Facets里添加Web支持，把web.xml路径指到刚才创建的WEB-INF下。
6. 在Run/Debug Configurations里，点+号添加Tomcat Server -> Local，把Deployment选项卡里的Artifact加上这个项目的war exploded包。

这里有个超容易踩的坑——用Maven创建项目时，默认没有src/main/webapp目录，但webapp目录是Web项目的标准目录结构，Tomcat要求JSP和静态资源都放在这个目录下面。所以第四步必须手动创建。

新建JSP文件的时候，右键webapp目录，选择New -> JSP/JSPX，文件命名为login.jsp。IDEA新建的JSP文件默认是带<%@ page contentType="text/html;charset=UTF-8" language="java" %>头部的，这个头部保留即可。

4. 核心模块实现：从登录到业务闭环

4.1 用户登录与Session管理

登录模块是所有管理系统的入口，也是实现得最烂的一个模块——很多同学的登录就是个摆设，用户名密码写死在页面里。下面我演示一个可靠的实现方案。

登录页login.jsp的核心代码结构：

<%@ page contentType="text/html;charset=UTF-8" language="java" %> <html> <head><title>出租公司管理系统 - 登录</title></head> <body> <form action="login" method="post"> 用户名：<input type="text" name="username"/><br/> 密码：<input type="password" name="password"/><br/> <input type="submit" value="登录"/> </form> <span style="color:red;">${errorMsg}</span> </body> </html>

对应处理登录请求的LoginServlet：

@WebServlet("/login") public class LoginServlet extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String username = request.getParameter("username"); String password = request.getParameter("password"); // 此处BaseDao是个JDBC操作工具类，后面会讲 User user = BaseDao.findUserByUsernameAndPassword(username, password); if (user == null) { request.setAttribute("errorMsg", "用户名或密码错误"); request.getRequestDispatcher("/login.jsp").forward(request, response); } else { HttpSession session = request.getSession(); session.setAttribute("currentUser", user); // 根据角色跳转不同首页 if ("admin".equals(user.getRole())) { response.sendRedirect("admin/index.jsp"); } else { response.sendRedirect("carshop/index.jsp"); } } } }

这段代码里有几个细节值得展开讲一讲：

第一，用request.getSession()创建会话后，用户的身份信息就绑定到了服务端的session对象上。之后任何页面想判断“当前是否有人登录”，只需要从session里取currentUser，取不到就重定向回登录页。这个机制是HttpSession的默认行为，服务端会为每个会话生成唯一的JSESSIONID，浏览器通过Cookie把它带回来，从而实现有状态访问。

第二，为什么失败时要forward而不是redirect。forward是在服务端内部把请求转发给login.jsp，整个过程是一次请求；redirect是让浏览器重新发起新请求。forward能携带request.setAttribute()设置的数据，所以${errorMsg}能渲染出来；如果用redirect，这个属性就丢了。很多同学栽在“为什么重定向之后页面拿不到错误提示”这个问题上，原因就在这里。

第三，牢记用过滤器保护受保护的页面。不管哪个角色，访问任何*.jsp页面之前都应该经过权限检查。一个简单的LoginFilter：

@WebFilter("/admin/*") public class LoginFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; HttpSession session = request.getSession(false); if (session == null || session.getAttribute("currentUser") == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } chain.doFilter(req, resp); } }

这个过滤器的作用是：只要访问/admin/下的资源，就强制检查是否已登录。注意request.getSession(false)这个写法，它告诉你“如果有session就返回，没有就返回null”，不要用getSession(true)，否则你会为每个未登录的请求都创建一个无意义的session。

4.2 车辆管理模块实现

车辆管理是整个系统的数据基础。我会用一个CarServlet统一处理车辆相关的所有操作，通过action参数区分不同的方法调用——这是最朴素的REST风格，也是最容易让评委看懂的结构。

核心逻辑如下：

• 列表查询：action=list，从数据库查出所有车辆，放入request作用域，forward到carList.jsp展示。
• 新增车辆：action=add，接收表单参数，组装成Car对象，调用DAO层插入数据库。
• 编辑车辆：action=edit，先根据ID查出原车辆信息回显到页面，再提交修改。
• 删除车辆：action=delete，根据ID删除，注意判断该车是否有未完成订单，有则禁止删除。

JSP页面里必须引入JSTL标签库才能优雅地遍历数据。carList.jsp展示表格的核心结构：

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <table> <tr> <th>车牌号</th><th>品牌</th><th>型号</th><th>日租金</th><th>状态</th><th>操作</th> </tr> <c:forEach items="${carList}" var="car"> <tr> <td>${car.carNo}</td> <td>${car.brand}</td> <td>${car.model}</td> <td>${car.dailyRent}</td> <td> <c:choose> <c:when test="${car.status == 0}">可出租</c:when> <c:when test="${car.status == 1}">已出租</c:when> <c:when test="${car.status == 2}">维修中</c:when> <c:otherwise>已停用</c:otherwise> </c:choose> </td> <td> <a href="car?action=edit&id=${car.id}">编辑</a> <a href="car?action=delete&id=${car.id}" onclick="return confirm('确定删除吗？')">删除</a> </td> </tr> </c:forEach> </table>

这里有几个技巧我要专门强调一下。

JSTL的<c:choose>是if-else的替代品。在JSP里不要用<% if(...) %>这种脚本代码，那会让页面变得极其混乱，而且难以维护。用<c:choose>和<c:when>组合，页面源码干净，逻辑一目了然。如果你用了<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>，却发现标签不生效，那是因为缺了jstl.jar依赖——这是毕设里最常见的错误之一，后面部署章节我会专门讲。

车辆状态的数字枚举要在数据库层和页面层同时维护。数据库里存0、1、2这样的数字，页面展示时用<c:choose>映射成中文。为什么不用字符串直接存“可出租”？因为数字枚举更利于SQL查询和状态判断，比如WHERE status=0就能快速查出所有可出租车辆，而且状态码可以在Java里定义成常量，强制约定取值范围。

千万别把删除做成物理删除。我建议表里加一个is_deleted字段，逻辑上隐藏数据就行。车辆可能关联了大量历史订单，一旦物理删除，订单表里车辆那部分数据就全变成脏数据了。这一点在答辩时提出来，会显得你考虑问题非常周到。

4.3 订单流程与状态管理

订单模块是整个系统的灵魂。我见过太多毕设把订单做成了“新增记录+删除记录”的简单CRUD，这完全体现不出业务理解。合理的订单流程必须覆盖从预订到结算的完整生命周期。

我的实现思路是这样的：

OrderServlet里定义了以下几个方法：

• createOrder（客户下单）：客户从车辆列表中选择可租车辆，填写租车时间段，系统自动根据日租金和天数计算预估总价。
• auditOrder（员工审核）：员工查看待审核订单，审核通过后，该车辆状态同步改为“已出租”。
• deliverCar（出车）：确认客户已取车，订单状态变为“出租中”。
• returnCar（归还结算）：登记实际还车时间，系统计算实际金额，支持输入优惠或违约金，最终生成费用明细。
• cancelOrder（取消订单）：待审核和已确认状态的订单可以取消，同步释放车辆资源。

订单创建时的金额计算，我强烈建议在服务端计算，而不是页面端。前端页面显示的金额只是估算，最终结算以后端为准。核心计算逻辑：

// 计算租车天数：不足一天按一天算 long days = (endTime.getTime() - beginTime.getTime()) / (24 * 3600 * 1000); if ((endTime.getTime() - beginTime.getTime()) % (24 * 3600 * 1000) > 0) { days = days + 1; } BigDecimal totalAmount = car.getDailyRent().multiply(new BigDecimal(days));

为什么要用BigDecimal而不是double类型存金额？做财务相关的数据，浮点数的精度误差是致命的。你用0.1+0.2就体会到了，double算出的是0.30000000000000004。租金计算涉及钱，必须用BigDecimal，这也是答辩时一个很出彩的细节。

订单状态变化的同时，必须同步修改车辆状态。这两步操作要放在同一个Service方法里，并且加上事务控制。JDBC里的事务控制很简单：

Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 关闭自动提交 // 1. 更新订单状态 orderDao.updateStatus(orderId, 2); // 2. 更新车辆状态 carDao.updateStatus(carId, 1); conn.commit(); // 统一提交 } catch (Exception e) { if (conn != null) { conn.rollback(); // 出错回滚，保证数据一致性 } e.printStackTrace(); } finally { if (conn != null) { conn.setAutoCommit(true); conn.close(); } }

事务是保证数据一致性的底线。试想一下，如果没有事务，订单状态更新成功了，但车辆状态更新失败，这辆车就出现了“被租了但状态还是可出租”的脏数据。这个细节老师必然会追问，提前准备好就对了。

4.4 JSP页面显示层技巧：EL表达式与JSTL

整个系统里，JSP页面的写法决定了你的代码质量。我见过太多同学还在用<% %>直接在页面里写循环、写JDBC，整个页面几百行Java脚本，又丑又难调。正确的打开方式是：

• EL表达式（${xxx}）负责取值。
• JSTL标签（<c:forEach>、<c:if>等）负责逻辑控制。
• 页面里禁止出现任何Java脚本代码。

EL表达式的三个作用域取值规则要理解：${username}会依次从page、request、session、application四个作用域里查找。所以你在Servlet里request.setAttribute("carList", list)，页面直接用${carList}就能取到，不用写<%= request.getAttribute("carList") %>。

JSTL我实际用到最多的标签是这5个：

同时有一点必须注意：JSP页面里URL路径要使用${pageContext.request.contextPath}。这句话在天然避免了一大类Bug：如果你的项目不是部署在Tomcat根目录，而是部署在http://localhost:8080/car-rent/这个路径下，那么页面上的/login链接如果不加项目名前缀，就会跳转到http://localhost:8080/login，直接404。

我习惯的写法是：

<c:set var="ctx" value="${pageContext.request.contextPath}"/> <link rel="stylesheet" href="${ctx}/css/style.css"/> <a href="${ctx}/car?action=list">车辆列表</a>

这样无论项目部署在哪个上下文路径下，链接都不会错。

5. 打包部署与常见踩坑

5.1 传统JSP项目如何打包成war

做完项目总要部署演示。毕设阶段通常有两种运行方式：一种是直接用IDEA的Tomcat配置跑起来，另一种是打成war包放到服务器上的Tomcat里。前者适合开发，后者适合部署和答辩展示。

war包的打包方式取决于你的项目结构。

如果是Maven项目，在pom.xml里确认打包方式是war：

<packaging>war</packaging>

然后执行mvn clean package，在target目录下就会生成xxx.war。

如果是普通IDEA Web项目，选择Build -> Build Artifacts -> xxx:war -> Build，IDEA会在out目录里生成war包。我在实际使用中更推荐这种直接输出war的方式，因为很多学生项目不是Maven结构，强行用Maven还得重新理一遍目录。

有一个细节很容易忽略：war包的依赖问题。如果项目里用到了JSTL库、MySQL驱动、连接池组件，需要确认这些依赖的jar包是否被打进了war的WEB-INF/lib目录。如果用的是Maven且依赖是provided作用域（比如Tomcat自带的Servlet API），这些不会被包含在war包里，运行时Tomcat会提供；如果依赖范围设置错误，就会出现“本地能跑，部署后报ClassNotFoundException”的经典惨案。

5.2 Tomcat部署war包的完整步骤

本地开发环境和部署环境的分离是很多同学容易懵的地方。我先给一个最简单的、不做任何虚拟主机配置的直铺方式：

1. 下载对应版本的Tomcat。注意版本要和你的JDK匹配，比如Tomcat 9对应JDK 8及以上，Tomcat 10对应JDK 11及以上。
2. 把xxx.war直接复制到Tomcat的webapps目录下。
3. 在bin目录双击启动startup.bat（Windows）或执行./startup.sh（Linux）。
4. 浏览器访问http://localhost:8080/xxx/，Tomcat会在启动时自动把war解压成目录，这个目录名就是项目的上下文路径。

Tomcat默认端口是8080。如果你的8080端口被其他程序占用了，修改conf/server.xml里的<Connector port="8080">端口号即可。我遇到过一个学生，代码完全没问题，但端口一直被占用导致页面一直加载不出来，最后排查了半天才发现是之前启动过一次Tomcat进程没有关掉。

部署后第一次访问时报404，最常见的三个原因排查顺序：

• 项目有没有正常解压——看webapps目录下是否生成了解压后的文件夹？
• 访问路径是否带项目名——Tomcat默认不会把项目映射到根路径，http://localhost:8080访问的是Tomcat自带的ROOT应用，不是你的项目。必须访问http://localhost:8080/项目名/。
• web.xml部署描述符配置是否正确——<welcome-file-list>里是否配置了欢迎页？

5.3 路径、编码、jar包：三大经典坑

经典坑一：绝对路径写死在代码里。经常看到有人这么写：

String filePath = "D:/myproject/upload/xxx.jpg";

换一台机器部署，路径就失效了。正确做法是用相对路径搭建，比如把上传的文件放在项目的upload目录下，运行时通过request.getServletContext().getRealPath("/upload")动态获取物理路径。这样项目拷贝到任何环境都能运行。

经典坑二：中文乱码。乱码问题在JSP项目里太常见了。根源在于页面编码、请求编码、数据库编码三层没统一。一个靠谱的三件套配置：

• JSP页面头部：<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" %>
• Servlet里处理请求参数：request.setCharacterEncoding("UTF-8")
• 数据库连接串：jdbc:mysql://localhost:3306/car_rent?useUnicode=true&characterEncoding=UTF-8

这三层只要有一层忘记，中文显示就会出问题。而且如果你用POST请求提交表单，request.setCharacterEncoding("UTF-8")必须在读取任何参数之前调用，否则无效。GET请求参数的编码则需要在Tomcat的server.xml里配置URIEncoding="UTF-8"，这个坑非常隐蔽，因为中文GET参数会变成乱码，但post提交又是好的，排查起来很磨人。

经典坑三：JSTL标签完全不渲染。页面代码看着没问题，<c:forEach>就是没有被解析，按浏览器里显示为原始标签文本。原因是Tomcat的webapps项目里缺少jstl.jar和standard.jar。如果是Maven项目，在pom.xml里加：

<dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.2</version> </dependency>

如果不是Maven，就把两个jar包扔进WEB-INF/lib目录。这里再提醒一遍：JSTL需要完整的标签库实现，光有jstl-api是不够的，还得有range下的standard实现（1.2版本一般已经合并打包）。

6. 答辩准备与项目优化方向

6.1 答辩时老师最爱问的几个问题

答辩本质上是一场“证明你确实自己做完了这个项目”的对话。梳理了这么多年来的答辩现场，这些提问频率最高的点：

“你这个项目架构是什么？JSP在MVC里处于哪一层？”

这个问题的标准回答是：系统采用经典的MVC三层架构。JSP是视图层，只负责页面展示；Servlet是控制层，接收请求、调度业务逻辑；Service+DAO是模型层，处理业务规则和数据库交互。页面中通过EL表达式和JSTL标签展示数据，不在视图层编写任何业务代码。

“车辆状态和订单状态是怎么保证一致性的？”

这个问题的关键在于你有没有用数据库事务。回答思路是：添加和修改订单状态时，在同一次请求中通过setAutoCommit(false)关闭事务自动提交，先更新订单状态再更新车辆状态，两个操作一起commit。如果中间任何一个环节异常，则rollback整个事务，保证数据库不会出现“订单已确认但车辆没有锁定”的情况。到这里再补一句“未来可以引入声明式事务来统一管理”，加分。

“如果客户租车超时未还，系统怎么处理？”

两种思路。简单版：在归还登记时判断当前时间和计划还车时间，超时则自动计算违约金。进阶版：在订单状态里加入“待归还”状态，通过定时任务或定时触发器扫描所有超过计划还车时间但状态仍为“出租中”的订单，自动标记为超时。我建议至少把第一版做出来，它体现了系统的完整闭环。

“为什么选JSP而不是前后端分离？”

这个问题答好了反而能成为亮点。可以从以下几点说：第一，课程设计的教学目标偏向理解Java Web运行机制，JSP技术栈让学生能完整接触从HTTP请求到数据库访问的全链路；第二，服务端页面渲染模式在需要考虑SEO和信息全量展示的场景中仍有应用价值，例如内部管理系统对页面交互要求不高，服务端渲染更简洁；第三，在毕设的时间范围内，JSP方案能更快稳定交付。

6.2 如何给系统加亮点：从“能跑”到“有说服力”

做一个“能跑”的毕设不难，但想让老师眼前一亮，可以在这些方向上做文章：

加一层简单的数据可视化。不用引什么复杂的图表库，按月份统计营收和订单量，后台用<fmt:formatNumber>或者直接在DAO里写聚合SQL，然后在JSP页面用Bootstrap的进度条、表格把统计结果渲染出来。哪怕只是一张统计表，都比单调的CRUD有质感得多。

加一个Excel导出功能。用Apache POI导出订单列表到Excel文件，虽然技术含量不高，但非常实用，很多管理系统的真实需求里都有这一条。答辩时演示一下“导出本月订单”，业务完整度直接上一个档次。

密码加个哈希存。很多毕设项目的用户表密码都是明文存储在数据库里的。你在登录逻辑里引入MD5（进阶一点用BCrypt）对密码做摘要处理，并且在答辩时指出“数据库泄露也不会导致用户密码被直接读取”，这一句话就足够说明你是有安全意识的。

用连接池替代DriverManager。如果一个项目里到处都是DriverManager.getConnection()，答辩时基本都会被挑刺。换成Druid或C3P0连接池，在web.xml里初始化，虽然代码量增加不多，但说服力完全不同，因为连接池是企业级开发的标配。

6.3 以后还能往哪个方向扩展

答辩时老师常问的最后一类问题是“你这个系统以后还能怎么完善”。

这套JSP系统比较自然的演进路径是：

• 第一层演进：把JSP换成Thymeleaf或FreeMarker模板引擎，保持服务端渲染的模式不变但获得更好的模板语法支持。
• 第二层演进：将单体应用拆分成多个Maven模块，引入Spring Boot作为基础设施，保留现有页面设计，把底层数据访问切换到MyBatis。
• 第三层演进：前后端彻底分离，前端用Vue或React实现单页应用，后端提供RESTful API接口。

我会建议你在答辩词里只讲到第一层和第二层之间的跨度，保持谦虚的“未来展望”姿态——你不需要真做出来，但你要能说清楚这个系统的技术边界在哪里，哪些是现在的问题，哪些是未来的方案。

我在实际接触到的毕设项目里，见过太多“功能做了但不知道为什么要这么做”的同学。写代码的能力固然重要，但答辩考验的是你能不能把自己的技术决策讲清楚。这篇文章里讲的每一个设计点——为什么用枚举存状态、为什么用BigDecimal算钱、为什么订单状态和车辆状态要写在一个事务里——都是在帮你构建“决策-实现-解释”的闭环能力。

最后分享一个我个人带项目常说的话：毕业设计是你第一次以“负责人的姿态”完结一个完整项目，哪怕它只是管理系统的CRUD，也要把它当成一个真正的产品来打磨。把数据表设计得严谨一点，把页面做得干净一点，把事务和安全底线守住，让代码里的每一个决定都经得起追问，你交出的就不只是一个答案，而是你对“写代码”这件事的完整理解。