企业官网建设流程全解析

简介：基于Java的恒鑫物资租赁系统是一套完整的毕设/工程项目包，采用MVC模式将JSP作为视图层、MySQL作为数据库，针对租赁站器材品种多、费用计算复杂等场景，实现了用户管理、订单管理、资金结算和材料租赁等核心模块，适合有一定Java Web基础、从事物资管理开发的研发人员参考学习。资源包内共17个文件，涵盖源码压缩包、SQL数据库脚本、毕业论文（doc/docx/pdf）、开题报告、答辩PPT、系统截图以及部署手册和视频辅助资料，整体约43MB，目录按“代码—论文—截图—数据库—视频”划分，便于快速定位。目前已有40人学习下载。借助源码和SQL脚本可在MyEclipse与Tomcat 6.0环境下直接部署运行；配套论文、答辩PPT和操作视频则帮助理解系统设计思路，完成毕业设计或企业小型租赁管理系统的二次开发。

1. 恒鑫物资租赁系统：一套JSP+MySQL毕业设计到底在做什么

如果你正在为毕业设计选题发愁，或者刚拿到“基于Java的恒鑫物资租赁系统”这个题目还没理清头绪，这篇笔记就是给你准备的。它的核心是典型的Java Web三层结构：浏览器里的JSP页面负责展示，Servlet充当控制器，JavaBean和DAO处理业务与数据库交互，MySQL在底层存物资、客户、租赁订单这些数据。物资租赁的业务闭环——登录、浏览物资、下单租赁、归还结算、超期计算——在这个系统里全都能跑通。配套的项目源码、辅助视频、毕业论文和答辩PPT，能让你把整个项目从开发到答辩一次串完。适合三类人：正在做毕设的计算机专业学生、想把Java Web全链路打通的自学者、需要快速拿出一套可演示系统的在职开发者。这类项目最大的价值不是技术多新，而是MVC的分层思想能在一套小而完整的业务里看得明明白白。

2. MVC架构落地：Servlet当控制器，JavaBean当模型，JSP只负责展示

2.1 毕设选型：JSP+Servlet+MySQL为什么至今仍是经典组合

现在企业里Spring Boot几乎成了默认选项，为什么毕设还大量使用JSP+Servlet这套组合？从教学角度看，MVC三个角色被硬生生拆成了三种文件：JSP、Servlet、JavaBean，每一层都能单独打开看，不像Spring Boot那样注解一多，新手容易分不清谁在干什么。从答辩角度看，导师问“你们项目怎么分层的”，你能指着一行行代码说清楚——这是JSP页面，那是Servlet控制器，旁边是数据访问类。这种直观性是框架封装后很难给到的。

这套组合在技术选型上没有弯弯绕绕：JDBC连MySQL，Servlet接收请求，JSP渲染HTML。正因如此，热词里“spring mvc”和“idea创建spring mvc项目”这些内容可以作为对比理解——Spring MVC本质也是MVC，只是把控制器变成了注解标注的类，把模型交给了MyBatis或JPA去管。理解JSP+Servlet之后，再切到Spring MVC几乎是无痛的，只是省掉了手写Servlet配置那一步。

我做毕设指导这多年，最常见的翻车不是代码写不出来，而是把业务逻辑全堆在JSP页面里，或者在Servlet里拼HTML字符串。这两种做法都会让答辩变成灾难。记住一句话：JSP里不该出现Java业务逻辑，Servlet里不该出现HTML标签。后面每一章都围绕这条原则展开。

2.2 Model层：用JavaBean和DAO把物资与订单变成可操作对象

Model层分两部分：JavaBean是数据的载体，对应数据库里的一张表；DAO（Data Access Object）负责对表做增删改查。物资租赁系统里典型的JavaBean是Material（物资）和RentalOrder（租赁订单），字段跟数据库列一一对应。JavaBean必须提供无参构造和getter/setter，这样JSP才能用EL表达式${material.name}直接取属性。

DAO层的核心操作用JDBC完成。下面这段代码是从物资表里按id查一条记录的典型写法，注释里标了每一步在干什么：

public Material findById(int id) { Connection conn = null; PreparedStatement ps = null; ResultSet rs = null; Material material = null; try { // 1. 从JDBCUtil获取连接，内部封装了DriverManager.getConnection conn = JDBCUtil.getConnection(); // 2. 预编译SQL，用?占位符避免拼接字符串带来的SQL注入风险 String sql = "SELECT * FROM t_material WHERE id = ?"; ps = conn.prepareStatement(sql); // 3. 参数从1开始编号，setInt对应数据库的int列 ps.setInt(1, id); rs = ps.executeQuery(); if (rs.next()) { material = new Material(); material.setId(rs.getInt("id")); material.setName(rs.getString("name")); material.setCategory(rs.getString("category")); material.setStock(rs.getInt("stock")); material.setRentPrice(rs.getBigDecimal("rent_price")); } } catch (SQLException e) { e.printStackTrace(); } finally { // 4. 释放资源，顺序与打开顺序相反：rs先关，再ps，最后conn JDBCUtil.close(rs, ps, conn); } return material; }

这段代码你会在每个DAO类里看到相似结构。参数说明：JDBCUtil.getConnection()内部通常读一个db.properties文件拿到url、用户名、密码；PreparedStatement的setInt(1, id)里的1是第一个占位符，不是id值。finally里的关闭操作不能省——JDBC连接是稀有资源，不关的话数据库连接数很快会打满，后面避坑章节细说。

2.3 View与Controller：JSP提交表单，Servlet分流请求

Controller层在JSP+Servlet架构里是若干个Servlet类。它们不直接操作数据库，而是接收JSP传来的参数，调用DAO层方法，再把结果放到request或session域中，最后转发或重定向到JSP页面。看一个登录请求的完整链路，这是理解MVC请求流转的最小闭环：

@WebServlet("/login") public class LoginServlet extends HttpServlet { private UserDao userDao = new UserDao(); @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // 1. 设置请求编码，解决中文用户名乱码，必须放在读取参数之前 request.setCharacterEncoding("UTF-8"); String username = request.getParameter("username"); String password = request.getParameter("password"); // 2. 调用业务层验证账号密码，返回User对象或null User user = userDao.findByUsernameAndPassword(username, password); if (user != null) { // 3. 登录成功，把用户信息放进session，后续过滤器从这里判断登录状态 HttpSession session = request.getSession(); session.setAttribute("loginUser", user); // 4. 重定向到物资列表页，PRG模式防止刷新重复提交 response.sendRedirect(request.getContextPath() + "/materialList"); } else { // 5. 失败则回登录页，并带一个错误提示参数 request.setAttribute("errorMsg", "用户名或密码错误"); request.getRequestDispatcher("/login.jsp").forward(request, response); } } }

逻辑说明：@WebServlet("/login")把Servlet映射到“/login”这个URL，JSP里表单的action="login"提交到这里。forward和sendRedirect有本质区别——前者是服务器内部跳转，地址栏不变，request属性还在；后者是浏览器重新发起请求，需要request.getContextPath()拼上下文路径（也就是项目部署名）。这是新手最容易踩坑的地方，后面避坑章节单独说。

对应地，JSP里只做一件事：展示结果。用${loginUser.username}取值，用${errorMsg}显示错误信息。业务逻辑在Servlet里完成，页面只负责接收。看到JSP里出现<% if(...) {%>这样的Scriptlet，就要意识到分层已经被破坏了。

3. 数据库设计从租赁业务倒推：五张表与JSP核心页面怎么做才不返工

3.1 MySQL表结构设计：从物资到租赁订单的字段划分

先想清楚业务有哪些核心对象：谁在租（用户）、租什么（物资）、租了多久（订单）、什么时候还（归还记录）、谁管理（管理员）。从这五个对象倒推，至少需要五张表。设计表的时候我一般遵循一个经验：每个表都加id主键、create_time创建时间、update_time更新时间这三个通用字段，后面排查数据问题时会省很多事。

下面是这个系统的核心表结构，注意字段类型的选择直接决定了JavaBean里用Integer还是BigDecimal：

-- 用户表：前台租赁客户 CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '用户ID', username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(100) NOT NULL COMMENT '密码，建议MD5加密存储', real_name VARCHAR(30) COMMENT '真实姓名', phone VARCHAR(20) COMMENT '联系电话', id_card VARCHAR(18) COMMENT '身份证号，用于线下核验', status TINYINT DEFAULT 1 COMMENT '1正常 0禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' ); -- 物资表：可租赁的物料 CREATE TABLE t_material ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT '物资名称', category VARCHAR(50) COMMENT '分类：脚手架/发电机/切割机等', stock INT DEFAULT 0 COMMENT '当前库存数量', rent_price DECIMAL(10,2) NOT NULL COMMENT '日租金单价', deposit DECIMAL(10,2) DEFAULT 0 COMMENT '押金', status TINYINT DEFAULT 1 COMMENT '1可租 0已下架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 租赁订单表：一次租赁的核心记录 CREATE TABLE t_rental_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(30) NOT NULL UNIQUE COMMENT '订单编号，格式YYYYMMDD+随机数', user_id INT NOT NULL COMMENT '租用用户', total_deposit DECIMAL(10,2) COMMENT '总押金', total_rent DECIMAL(10,2) COMMENT '已结算租金', status TINYINT COMMENT '1租赁中 2已归还 3已逾期', rent_date DATE COMMENT '租出日期', expect_return_date DATE COMMENT '预计归还日期', actual_return_date DATE COMMENT '实际归还日期', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 订单明细表：一个订单可租多种物资 CREATE TABLE t_order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL COMMENT '所属订单ID', material_id INT NOT NULL COMMENT '物资ID', quantity INT NOT NULL COMMENT '租用数量', unit_price DECIMAL(10,2) COMMENT '当时租金单价', item_status TINYINT COMMENT '1未归还 2已归还' ); -- 管理员表：系统后台操作人 CREATE TABLE t_admin ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL );

参数说明：DECIMAL(10,2)存金额避免float精度丢失；DATETIME存日期时间，DATE存日期，JavaBean里对应LocalDateTime和LocalDate；order_no设计成业务编号而不是直接用自增id，是为了后续线下沟通时报号方便。这些细节在毕业论文的数据表设计章节里可以展开写两页，是凑字数和体现思考的好素材。

3.2 JSP关键页面：登录页、物资列表、租赁登记与归还结算

JSP页面虽然有多张，但骨架大同小异。登录页是最简单的，只有一个form表单。物资列表页则是整个系统信息量最大的页面，要展示物资名称、分类、库存、日租金，还要提供租赁入口。下面这段代码是物资列表页的核心循环，用JSTL的c:forEach替代Java代码块，页面干净且能正常被EL表达式解析：

<%@ page contentType="text/html;charset=UTF-8" language="java" %> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <html> <head> <title>物资列表</title> </head> <body> <h3>可租赁物资清单</h3> <table border="1" cellpadding="8"> <tr> <th>编号</th><th>名称</th><th>分类</th> <th>库存</th><th>日租金</th><th>操作</th> </tr> <%-- 遍历Servlet放进request域的materialList --%> <c:forEach items="${materialList}" var="m"> <tr> <td>${m.id}</td> <td>${m.name}</td> <td>${m.category}</td> <td>${m.stock}</td> <td>${m.rentPrice}</td> <td> <a href="rentalForm?materialId=${m.id}">租赁</a> </td> </tr> </c:forEach> </table> </body> </html>

逻辑说明：${materialList}是Servlet里用request.setAttribute("materialList", list)放进去的集合，JSTL标签从request域自动取出来遍历。${m.id}触发JavaBean的getId()方法，这正是JavaBean要写getter的原因。页面顶部声明了JSTL标签库的uri，必须与导入的jar包版本对应，否则会报can not find the tag library descriptor。现在的Tomcat一般用JSTL 1.2版本，标签库uri是http://java.sun.com/jsp/jstl/core。

租赁登记页相对复杂，需要回显物资信息：下拉框显示物资名称、输入框填租赁天数、系统自动算出预计归还日期。日期计算用JavaScript在浏览器端做也可以，但要在论文里写明白，更推荐在Servlet后端用LocalDate.now().plusDays(n)计算，页面只展示结果。这样避免前端改了系统时间导致日期错乱。

3.3 列表排序与模糊检索：mysql排序、分页、LIKE在页面上的落点

热点搜索词里有“mysql排序”“mysql在windows10上怎么安装”“mysql安装配置教程”，这里把排序和检索的落点讲清楚。物资列表页的排序需求很常见：按租金从低到高、按库存从多到少。这不该在Java内存里做，而是直接写进SQL让MySQL完成，否则数据量大了页面加载会明显变慢。典型写法：

// 按租金升序：价格从低到高，方便客户挑便宜的 String sql = "SELECT * FROM t_material WHERE status = 1 ORDER BY rent_price ASC"; // 按库存降序：库存多的排在前面，优先推荐现货充足物资 String sql = "SELECT * FROM t_material WHERE status = 1 ORDER BY stock DESC"; // 模糊搜索：名字或分类命中关键词，常用于顶部搜索框 String sql = "SELECT * FROM t_material WHERE name LIKE ? OR category LIKE ?"; ps.setString(1, "%" + keyword + "%");

参数说明：ORDER BY在WHERE之后执行，所以过滤和排序的顺序别写反；LIKE的%是通配符，放在关键词两侧表示“包含匹配”。注意LIKE会导致全表扫描，但毕设数据量通常只有几十上百条，完全够用。分页的话，MySQL用LIMIT offset, pageSize，offset等于(currentPage-1)*pageSize。我见过不少人在Java里先把所有数据查出来再循环截取，数据量小感觉不出来，答辩时被问性能优化会很尴尬。

4. 核心业务逻辑串起来：租赁下单、库存扣减、会话过滤与权限控制

4.1 租赁下单的完整请求链路：从JSP表单到Servlet再到DAO

租赁下单是系统里最重要的一条链路：用户在物资列表页点“租赁”，系统跳到登记页，用户填租赁天数、数量，点提交后请求到达Servlet。Servlet要做的事情按顺序是：接收参数、查物资确认库存够不够、计算押金和预计还期、写入订单表和明细表、扣减库存。任何一步失败，整个操作都要回滚。

下面这段代码是租赁单Servlet的核心逻辑，注意事务的写法——事务必须加在业务方法上，而不是DAO的单个方法里。很多新手把事务写在DAO的insert方法内部，结果insert和update变成了两个独立事务，前一个成功、后一个失败时数据就乱了：

@WebServlet("/createRentalOrder") public class CreateRentalOrderServlet extends HttpServlet { private RentalOrderService orderService = new RentalOrderService(); @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); try { // 1. 从表单取值：物资id、租赁数量、租赁天数 int materialId = Integer.parseInt(request.getParameter("materialId")); int quantity = Integer.parseInt(request.getParameter("quantity")); int days = Integer.parseInt(request.getParameter("days")); // 从session拿当前登录用户id，而不是从表单传——防止伪造 User user = (User) request.getSession().getAttribute("loginUser"); // 2. 调用业务方法，内部开启事务 boolean success = orderService.createOrder(user.getId(), materialId, quantity, days); if (success) { // 3. 成功就重定向到订单列表，避免F5刷新重复下单 response.sendRedirect(request.getContextPath() + "/myOrders"); } else { request.setAttribute("errorMsg", "库存不足，下单失败"); request.getRequestDispatcher("/rentalForm.jsp").forward(request, response); } } catch (Exception e) { e.printStackTrace(); response.sendRedirect(request.getContextPath() + "/materialList"); } } }

逻辑说明：orderService.createOrder()内部要依次执行“查库存、插入订单、插入明细、扣库存”四步。Connection从线程本地变量ThreadLocal中获取，保证同一个请求里的所有DAO操作共用同一个连接，这样commit和rollback才能覆盖全部操作。参数说明：days必须做合法性校验，如果用户提交了负数或超过最大值，后端还得拦一道，不能只靠前端表单限制。这里就用到了前面Model层提到的RentalOrderService，它是业务层，放在Servlet和DAO之间，这也是MVC架构里容易被忽略的一层。

4.2 归还结算与超期罚金：日期差计算和事务边界

租赁系统区别于普通商城系统的核心业务是“还”和“罚”。还物资时要根据订单的actual_return_date与expect_return_date比较，超过就按天算罚金。计算日期差在Java 8之后用ChronoUnit.DAYS.between(expectDate, actualDate)，两个参数都是LocalDate类型，避免了以前用java.util.Date手动算毫秒差的麻烦。

归还业务的流程是：管理员或用户本人选择订单，系统查出明细表中未归还的物资，逐项标记为已归还，同时把物资库存加回去。这里有两个边界情况需要专门处理：部分归还和超期未还。部分归还意味着明细表里同一订单的多条记录要分开更新，库存也要按对应数量加；超期未还则是系统里要有一个定时任务或手动查询，把所有超过expect_return_date且状态仍为1的订单批量标记为“已逾期”。

存放日期字段时，MySQL用DATE类型，JDBC里通过rs.getObject("rent_date", LocalDate.class)直接拿到LocalDate。这个写法避免了getDate()返回java.sql.Date再手动转换的麻烦，是JDBC 4.2之后支持的特性。

4.3 会话状态与权限过滤：为什么不能用隐藏字段判断登录

这是MVC项目里必须答对的面试题，也是避坑章节会再次展开的问题。判断用户是否登录，唯一可靠的方式是检查HttpSession里有没有对应的登录标记，比如之前登录成功时放的session.setAttribute("loginUser", user)。不能依赖JSP页面的隐藏字段<input type="hidden" name="userId">——因为用户可以篡改表单提交内容，把userId改成别人的，就能冒充他人下单。

Servlet里的标准做法是用Filter（过滤器）统一拦截。下面是一个最简的登录过滤器，在Web.xml或@WebFilter注解中配置要拦截的URL：

@WebFilter(urlPatterns = {"/materialList", "/createRentalOrder", "/myOrders"}) public class LoginFilter implements Filter { @Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; // 从session拿登录标记，没拿到就跳回登录页 Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } // 已登录就放行，继续执行后续Servlet chain.doFilter(req, resp); } }

参数说明：urlPatterns可以写多个路径，也可以写/*拦截全部请求，但那样登录页本身也会被拦住，需要在过滤器里放行login.jsp和login这个Servlet。权限控制同理，管理员的操作接口（比如物资上下架）除了要登录，还要校验loginUser的角色字段是不是管理员。过滤器里做权限判断时，记得把HttpServletRequest的强转放在第一位，否则拿不到session，这是很容易忽略的小细节。

4.4 并发下的库存扣减：下单时物资数量怎么保证不为负

物资租赁系统里库存扣减是最容易出现数据一致性问题的地方。教务系统、电商系统、物资系统都面临同一个经典问题：两个人同时租最后一件设备，两个请求都读到库存为1，都判断“够”，结果库存变成-1。解决方式是SQL层面的原子更新，而不是在Java里select出来判断再update。

// 扣减库存：stock = stock - ? 并且限定stock >= ?，影响行数为0说明库存不够 String deductSql = "UPDATE t_material SET stock = stock - ? WHERE id = ? AND stock >= ?"; ps.setInt(1, quantity); ps.setInt(2, materialId); ps.setInt(3, quantity); int rows = ps.executeUpdate(); if (rows == 0) { throw new RuntimeException("库存不足，扣减失败"); }

逻辑说明：UPDATE语句里的stock >= ?条件让数据库自己判断——如果当前库存小于要扣的数量，影响行数就是0，程序捕获后抛出异常，触发整个事务回滚。这样即使十个请求同时进来，MySQL行锁也会让它们排队执行，后到的因为stock不满足条件而失败。这个方案比先SELECT再UPDATE省掉了一次网络往返，也杜绝了“检查与更新之间被别人插一脚”的竞态条件。事务回滚后，之前插入的订单和明细也会一并撤销，不会出现“单子建了但库存没减”的状态。理解了这个场景，本质上就理解了MySQL锁和事务ACID在实际业务里的应用，这在java面试题里也常被问到。

5. JSP+MySQL项目避坑手册：从中文乱码到数据库连接爆满的8个排查点

5.1 中文乱码：请求编码、响应编码、MySQL连接参数必须统一

现象：页面上中文正常，但往数据库写入后变成??，或者从数据库读出来的中文全是乱码。

原因：三个环节的编码不一致——浏览器发送请求时用的编码、服务器响应用的编码、MySQL客户端连接的编码。只要有一个是ISO-8859-1或GBK，数据就出错。

解决：第一，Servlet的doPost方法里第一行写request.setCharacterEncoding("UTF-8")，必须放在读取任何参数之前；第二，JSP页面顶部contentType="text/html;charset=UTF-8"；第三，JDBC连接URL追加参数?useUnicode=true&characterEncoding=utf8；第四，MySQL建库时指定DEFAULT CHARSET=utf8mb4，utf8mb4比utf8多了对emoji和生僻字的支持。四个点都对齐，乱码问题基本绝迹。如果已经乱码了，补救方法是对取到的字符串做new String(str.getBytes("ISO-8859-1"), "UTF-8")，但这是后悔药，应该在源头拦截。

5.2 数据库驱动版本：MySQL 5.7与8.0的Driver类名变化

现象：项目本地跑得好好的，换一台电脑部署后启动直接抛ClassNotFoundException: com.mysql.jdbc.Driver。

原因：驱动包版本和MySQL服务端版本不匹配。MySQL 5.7及更早版本的驱动类名是com.mysql.jdbc.Driver，8.0之后官方驱动改成了com.mysql.cj.jdbc.Driver。如果从网上下载的代码用的是旧类名，配上MySQL 8.0的数据库，就报找不到类。反之也会报错，8.0驱动加载旧类名时还会额外打警告日志。

解决：统一用MySQL 8.0的驱动包，连接字符串写com.mysql.cj.jdbc.Driver。另外8.0驱动要求连接URL里必须带serverTimezone=Asia/Shanghai，否则会有时区报错The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。如果看到的错误带乱码，就是这个原因。装的是MySQL 5.7.44的话，数据库版本在5.7/8.0之间切换时要检查一遍db.properties里的driverClassName和url两行配置。

5.3 连接没关闭：Too many connections的排查和防御

现象：系统跑一段时间后，页面报错Too many connections，重启Tomcat后恢复，过一会又出现。

原因：DAO方法里Connection、PreparedStatement、ResultSet没有在finally里关闭。Java的垃圾回收不会自动回收数据库连接，连接数不断累积打满max_connections（默认151），后续请求全部排队或直接拒绝。这是JSP+Servlet项目最经典的资源泄漏问题，特征就是“越跑越慢，直到崩掉”。

解决：每个DAO方法都套try-catch-finally，在finally中按ResultSet、Statement、Connection的顺序关闭。更省心的做法是用DBUtils或Spring JDBC模板，它们内部帮你管理资源生命周期。如果项目代码量已经很大不好改，至少把JDBCUtil.close()封装做好，让每个DAO都调工具类而不是自己写关闭代码。排查时也可以用SHOW PROCESSLIST看哪些连接长期处于Sleep状态，数量持续增长就是泄漏的直接证据。

5.4 部署404与路径问题：contextPath的坑

现象：本地用IDEA跑正常，把war包丢到Tomcat webapps下部署后，点页面上的链接报404。

原因：IDEA部署时项目名通常和模块名一致，而Tomcat的webapps目录下war包解压目录名可能不一样。更关键的是，JSP里写href="/materialList"加斜杠开头，会被浏览器解析成“域名+端口/materialList”，完全忽略了项目上下文路径，也就是http://localhost:8080/你的项目名/materialList被写成了http://localhost:8080/materialList。

解决：页面里的绝对路径统一加${pageContext.request.contextPath}这个表达式，它自动展开成当前项目的部署根路径。比如<a href="${pageContext.request.contextPath}/materialList">。Servlet里的response.sendRedirect(request.getContextPath() + "/xxx")同理。这样项目改部署名也不受影响。如果看到404但确认路径没写错，先去Tomcat的logs/catalina.out看是不是Servlet映射没有编译发布，这种情况时常是没clean就hot deploy导致的。

5.5 表单重复提交：PRG模式避免F5刷新生成两笔订单

现象：用户下单后觉得页面没反应，多点了两次“提交”，结果系统里生成了两笔一模一样的订单。

原因：传统的Forward跳转是服务器内部响应，浏览器地址栏不变。用户按F5刷新时，浏览器重新发送最后一次POST请求，Servlet再次执行了一遍下单逻辑。这不是浏览器Bug，是HTTP协议的正常行为。

解决：采用PRG模式（Post-Redirect-Get）。Servlet处理完POST请求后，不forward而是sendRedirect到某个GET请求地址。比如下单成功后重定向到/myOrders，刷新这个页面只是重新查订单列表，不会再次下单。前面章节代码里已经用了这个模式。如果还想再加一层双重保护，可以在表单页面放一个随机token存session，Servlet校验通过后立即删除token，第二次请求因token不存在而拒绝。这在毕业论文的“系统安全性设计”一节里很有写头。

5.6 日期类型转换：java.sql.Date与java.util.Date的冲突

现象：从MySQL查出来的日期赋给JavaBean时报ClassCastException，或者日期数据存进去变成0点00分00秒。

原因：JDBC的rs.getDate()返回的是java.sql.Date，它继承自java.util.Date但把时间部分截断成00:00:00。如果你把java.sql.Date直接赋给JavaBean里声明为java.util.Date的字段，编译不报错，但后续打印时发现时分秒全丢了。反过来，往数据库里存java.util.Date时如果有时间部分，而列类型是DATE，MySQL会静默截断。

解决：Java 8之后的项目统一用java.time包：LocalDate对应MySQL的DATE，LocalDateTime对应DATETIME。查数据用rs.getObject("rent_date", LocalDate.class)，存数据用ps.setObject(1, localDate)。这套API类型匹配明明白白，从根上避免了传统Date的混乱。如果项目在JDK 7及以下没法用java.time，就老老实实每次拿到java.sql.Date后手动new java.util.Date(sqlDate.getTime())转换。毕设项目建议直接用JDK 8，不存在向后兼容的压力。

5.7 自带Tomcat与JDK版本不对付

现象：本地JDK 17运行项目，Splash页面加载正常，但打开JSP时报java.lang.NoClassDefFoundError: javax.servlet.ServletContext，或者直接ClassCastException。

原因：从Tomcat 10.0开始，Java EE更名为Jakarta EE，javax.servlet包全部改成了jakarta.servlet。老教程里import javax.servlet.*的代码在Tomcat 10上直接编译不过或运行报错。

解决：不管项目是拿来的源码还是自己写的，先确认Tomcat版本和依赖方向一致：用Tomcat 9及以下就保持javax.servlet命名空间，用Tomcat 10+就要把代码里所有javax.servlet替换成jakarta.servlet。热词里有“用idea2026.1.3基于maven创建一个spring mvc项目”的场景，创建的时候也要选对Tomcat版本。懒人方案是用内置Tomcat的Spring Boot，但在JSP+Servlet这种纯手写架构下，老老实实用Tomcat 9是多数教程和一揽子源码的默认选择。

5.8 管理员后台和前台用户用了同一张会话key

现象：管理员登录后台后发现前台操作用户的session数据串了，能直接看到管理员信息。

原因：登录时管理员和普通用户都执行了session.setAttribute("loginUser", user)，名字一样，类型不同。管理员登完再模拟用户登录，把loginUser对象覆盖了。如果项目用同一个Tomcat环境同时跑前后台两个模块，这就是隐患。

解决：两个角色的session键分开：管理员用session.setAttribute("adminUser", admin)，普通用户用session.setAttribute("loginUser", user)。过滤器里也分两套判断逻辑。数据库设计阶段就应该把管理员和用户分开表存储，这里就体现出来了。这个问题不严重，但答辩演示时如果你先登管理员再看用户功能，一翻车就容易紧张，影响后面的发挥。

6. 答辩前夜的三个动作：JSTL清理、演示数据、自测脚本

前面讲到JSP不该出现Scriptlet（<% %>里的Java代码），这一步在答辩前一定要做彻底。把页面里所有<% for、<% if、<% String换成JSTL的c:forEach、c:if和EL表达式。这个动作不改变任何业务功能，但翻开源码时观感截然不同。导师审论文时看到JSP里干干净净，知道你把MVC分层真正落到了代码上，这会直接在答辩印象分里体现出来。

第二个动作是准备一份“固定剧本”的演示数据。数据库里至少要预置：5个以上不同分类的物资、3个测试用户（含一个管理员）、2笔已完成归还的旧订单、1笔正在租赁中的订单、1笔故意超期的订单。演示时从超期订单切入讲“逾期判断逻辑”，比从登录页开始讲更抓注意力。我的血泪教训是当年答辩现场正讲到“无库存物资自动隐藏”，才发现库里那条测试物资库存字段是空的，怎么刷新都不出现，场面一度非常狼狈。后来每次演示前必跑一遍数据核对脚本。

第三个动作是准备一个业务自测脚本，按顺序覆盖：用户注册登录→浏览物资→模糊搜索→租赁下单→库存变化→归还结算→超期罚金→管理员后台上下架。每一步先在页面上操作，再打开MySQL客户端执行SELECT核对数据是否一致。比如下单后核对t_material.stock是否减少、t_rental_order是否新增记录、t_order_item是否插入明细，这三张表的数据对不齐就说明事务没做好。答辩时把这套脚本讲出来，能证明你不仅会调页面，还理解数据一致性，已经超出多数毕设的完成度了。希望这些经验能帮你在答辩前少走弯路。

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