JavaWeb超市订单管理系统课设：从四层架构到答辩避坑全指南

简介：基于Javaweb的超市订单管理系统课程设计项目，是一份面向计算机专业学生的完整课设参考方案，涵盖了登录鉴权、供应商管理、订单管理、用户管理等典型业务模块。压缩包共135个文件，包含25个Java源文件、24个JSP页面、24个JavaScript脚本、9个CSS样式及10个依赖JAR包，同时附带3个SQL数据库脚本，整体大小约2.69MB。前端基于Layui等组件库构建页面，后端采用Servlet+JSP+JDBC经典分层结构，解压后可直接导入Eclipse或IDEA运行，并支持通过SQL脚本快速还原数据库。项目代码结构清晰，适合学习JavaWeb基础开发、理解MVC模式与数据库交互流程。已有281人学习下载，对于正在完成超市订单类课程设计或想快速搭建Web管理系统的开发者，可提供一套可复用的代码骨架、页面模板与数据表设计，减少从零编码的重复工作。

1. 这个课设为什么值得做：超市订单管理系统到底在考什么

如果你正在为Javaweb课程设计翻来覆去找项目，看到“超市订单管理系统”这个标题，第一反应可能是“又是个烂大街的增删改查”。但恰恰是这类题目，最能拉开分数差距：老师看过的版本越多，越清楚哪些是套模板改名的、哪些是自己动手设计的。这个系统覆盖了Javaweb课设最核心的考点——Servlet + JSP + JDBC + MySQL的四层架构、会话跟踪、事务处理、分页查询、权限区分，几乎每个环节都能在答辩时被你拿出来当“亮点”讲。它适合两类人：一类是还差一个能跑通的课设来保底，另一类是已经能跑通但想冲高分、愿意在细节上多花两小时的人。这篇笔记会直接告诉你每一层的代码该看哪些、数据库脚本按什么顺序导、运行时要改哪几个参数、答辩时老师最喜欢从哪个角度刁难你。

2. 项目结构与数据库设计：先看懂再动手，别急着启动Tomcat

2.1 从zip到手把手解压：项目目录里每一层都是什么

拿到这个zip文件，第一步不是双击解压，而是先确认解压后的编码方式。常见做法是用解压工具解压到全英文路径下，比如D:\supermarket，不要带中文目录名。很多人第一次启动Tomcat失败，不是因为代码问题，而是MAVEN仓库或Tomcat路径里有中文或空格，控制台报错让人误判成代码故障。

解压后先打开顶层目录，典型的Javaweb课设工程大概是这个结构：

supermarket/ ├── sql/ # 数据库脚本，按文件名顺序导入 ├── src/ │ ├── com/supermarket/ │ │ ├── dao/ # 数据访问层，一般分为接口和实现 │ │ ├── service/ # 业务逻辑层，处理事务边界 │ │ ├── servlet/ # 控制层，接收请求、调用service、转发或重定向 │ │ ├── entity/ # 实体类，对应数据库表结构 │ │ └── util/ # 工具类（DBHelper、MD5、字符串处理） │ └── data/ # 有些项目把数据库脚本放这里 ├── web/ │ ├── index.jsp # 通常是登录页或首页 │ ├── WEB-INF/ │ │ ├── web.xml # Servlet映射、过滤器、监听器配置 │ │ └── lib/ # 依赖的jar包（没有lib的就是用Maven） ├── pom.xml # Maven工程标识，没有的话就是普通动态Web工程 └── README.md # 作者写的部署说明，先读这个

如果你看到的是这种src/web/sql三件套结构，说明它是不依赖Maven的传统Web项目，直接用Build → Artifacts → Web Application: Exploded方式部署。如果看到pom.xml，说明是Maven工程，但很多课设只是套了个Maven壳子，真正的依赖还是靠Tomcat库支撑，这点后续会细说。

我一般会让读者先做一件事：搜索项目里所有.jsp文件，看它们的pageEncoding是UTF-8还是GBK。这个细节决定了你导入IDEA后乱码的严重程度。如果项目里两种编码混用，就统一改成UTF-8再开始改代码，不然后面改一个页面崩一个页面。

2.2 数据库脚本的导入顺序与四张核心表的字段设计

打开sql目录，通常会看到多个.sql文件，有的项目拆成create_db.sql、init_data.sql，有的是一个文件包含了建库、建表、插入数据。拆分的项目必须按顺序导入，否则外键约束会直接报错。每次导入前先做一件事：确认数据库的字符集。

-- 建议在MySQL命令行或Navicat的查询工具里先执行这一句 CREATE DATABASE IF NOT EXISTS supermarket DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE supermarket;

为什么用utf8mb4而不是utf8？因为utf8在MySQL里最大只支持3字节，遇到emoji或生僻字会报错，虽然超市订单系统里不太可能出现emoji，但用utf8mb4是现在的主流习惯，答辩时提一句“我特意选用了utf8mb4以避免超长字符存储失败”就能加分。导入后千万别急着跑项目，先检查数据。

USE supermarket;之后建议执行的验证语句：

SHOW TABLES; SELECT COUNT(*) FROM orders; SELECT COUNT(*) FROM user;

以最常见的超市订单系统为例，核心不会少于四张表：用户表user（或sys_user）、供应商表supplier、订单表orders、订单详情表order_detail。订单表和订单详情表之间是一对多关系，这种拆分是课程设计里必须体现的“数据库设计基本功”。字段设计上最容易被答辩老师抓住的一个点是金额字段的类型，很多人用float或double存钱，这是专业度上最低级的问题，有经验的项目会用decimal(10, 2)。原因有两个：浮点型存小数时有精度误差，比如0.1加0.2显示0.30000000000000004；而decimal是定点数，按位数精确存储，做金额累加时不会出现分差。

如果你打开表结构发现用的是double，建议手动改成decimal(10,2)，然后在订单金额求和时用CAST(amount AS DECIMAL(10,2))保证输出干净。这个改动很安全，也不用动Java代码，但可以成为你答辩时的主动亮点。

2.3 连接配置：jdbc.properties里的三个必调参数

项目里一定会有一个数据库连接配置文件，可能叫jdbc.properties、db.properties或DBHelper.java，放在src根目录或util包下。在IDEA里展开src目录，找后缀为.properties的文件，打开后大概是这个风格：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/supermarket?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai&useSSL=false jdbc.username=root jdbc.password=123456

三个必调参数里唯一需要改的就是密码，root用户密码换成你本机实际的。新手最爱在这踩坑，直接把密码改成自己MySQL的密码，但忽略了serverTimezone参数。MySQL 8.0以上的驱动要求必须带时区，否则启动直接报The server time zone value '�й���ʱ��' is unrecognized。这串乱码就是时区问题的标准症状，看到它别慌，把serverTimezone改成Asia/Shanghai再重启。

第二个参数容易被忽略但更重要：characterEncoding=UTF-8。它决定Java从数据库读出来的中文是否能正确显示。如果你改了URL里的编码，控制台还是乱码，问题不一定在URL，而是MySQL服务端的character_set_server。验证方法是登录MySQL后执行SHOW VARIABLES LIKE 'character%';，如果结果里character_set_server不是utf8mb4，按2.1节的方式重启MySQL服务或者修改my.ini里的配置。

第三个参数useSSL=false在Javaweb课设里一定要保留，否则新版MySQL连接时会走SSL握手，导致启动慢几秒，个别环境下还会报证书错误。这三个参数改完之后，先独立测试连接，不要直接启动Tomcat：

java -cp "D:\Dependencies\mysql-connector-java-8.0.30.jar" ^ -Dfile.encoding=UTF-8 ^ -e "Class.forName(\"com.mysql.cj.jdbc.Driver\");"

不过这个命令只是验证驱动类能加载，稳妥的做法还是写三行Java测试代码：DriverManager.getConnection(url, user, password)如果能返回Connection对象，说明连接配置没问题，可以放心去启动项目。这一步过关后再谈页面运行逻辑，能帮你把环境问题和代码问题彻底分开。

3. 在IDEA里跑通全流程：从导入项目到订单提交成功

3.1 用IDEA打开Javaweb项目的完整配置

把Javaweb工程导入IDEA，常见的坑是直接用File → Open选目录，结果IDEA把它识别成一个空项目，看不到源码层次。我的做法是选择你项目的pom.xml（如果是Maven工程），或者选择web目录所在根路径（如果是纯Web工程），让IDEA按模块方式导入。

打开项目后，先确认IDEA识别出的SDK版本。课设项目一般基于JDK 8，如果你本机装的是JDK 17或21，大概率会出现两种问题：Tomcat版本不兼容导致java.lang.NoClassDefFoundError，或者编译时因为javax.servlet包不存在而报错。这时候不做大改动，建议按下面步骤配置：

File → Project Structure → Project Settings → Project SDK: 选择1.8（如果没有就去下载JDK 8） Language level: 8 Project Settings → Libraries 确认是否有 Tomcat 的库依赖： 如果有部署时报 ClassNotFound，按 + → Add Library → Tomcat

这一步是玄学重灾区，很多人按网上教程配了JDK 17照样跑通，因为项目本身没用到什么高级语法。但与其和版本较劲，不如老老实实下一个JDK 8。课设答辩时老师问“你这个项目用的什么版本的JDK”，你报JDK 8是最不容易被追问的版本。

配置完JDK后，还需要把当前项目的src目录标记为Sources Root。如果IDEA没有自动识别，项目里所有类都会变成橙色文件但无法跳转引用。在src文件夹上右键直接Mark Directory as → Sources Root即可。

3.2 启动Tomcat前必须检查的三处配置

第一次启动Tomcat，控制台里蹦出满屏异常堆栈基本是常态。有三处配置必须在启动前检查，否则错误信息会误导你以为是代码写错了。

第一处是web/WEB-INF/web.xml里的前端控制器映射。如果你这个项目用的是纯Servlet，会出现一批<servlet>和<servlet-mapping>标签。重点看<servlet-mapping>里的<url-pattern>是否和页面里的表单action一致。比如页面里提交到loginServlet，XML里映射的就必须是/loginServlet，大小写差异或漏掉斜杠都会导致提交后404。

第二处检查是web.xml顶部的<display-name>和<welcome-file-list>。welcome-file决定直接访问http://localhost:8080/时落在哪个页面。很多项目写的不是登录页而是某个index.jsp，如果这个页面里引用了未登录的用户数据，会抛空指针，这就是为什么有人说“项目启动了但是一访问就报错”。我的建议是直接把<welcome-file>从index.jsp改到login.jsp，确保启动即进入登录页。

第三处是Maven工程里的pom.xml对servlet-api的依赖范围。课设项目常见的错误是把servlet-api.jar按compile范围引入，导致和Tomcat自带的包冲突，启动时让你看到java.lang.LinkageError或奇怪的ClassCastException。正确做法是将范围改成provided：

<dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency>

provided的意思是编译期需要这个包，但运行时由Tomcat容器提供，能避免类加载器冲突问题。这三处检查完，才轮到Run → Edit Configurations里配置Tomcat。

3.3 一张订单怎么从前端页面流到数据库的

跑通项目之后，不要急着“点几个按钮就交差”。课设答辩比的是谁更清楚数据走向。以新增订单为例，我给你完整捋一遍这个流程，你可以照着项目代码找对应文件，答辩时按这条链路讲。

订单页面order/add.jsp里有一个表单，大概长这样：

<form action="${pageContext.request.contextPath}/order/add" method="post"> <input type="text" name="productName" placeholder="商品名称"/> <input type="number" name="quantity" placeholder="数量"/> <input type="text" name="price" placeholder="单价"/> <button type="submit">提交订单</button> </form>

提交之后，请求到达OrderServlet的doPost方法。Servlet层的代码逻辑很机械——取参数、组装实体、调Service、拿结果、跳页面：

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); String productName = request.getParameter("productName"); Integer quantity = Integer.valueOf(request.getParameter("quantity")); BigDecimal price = new BigDecimal(request.getParameter("price")); Order order = new Order(); order.setProductName(productName); order.setQuantity(quantity); order.setPrice(price); OrderService orderService = new OrderServiceImpl(); boolean isSuccess = orderService.addOrder(order); if (isSuccess) { response.sendRedirect(request.getContextPath() + "/order/list"); } else { request.setAttribute("error", "订单创建失败，请重试"); request.getRequestDispatcher("/order/add.jsp").forward(request, response); } }

这段代码里有几个细节值得你在答辩时主动讲出来。request.setCharacterEncoding("UTF-8")是用来处理POST请求的UTF-8提交数据的，否则中文商品名会乱码。Integer.valueOf和new BigDecimal用于把字符串参数转成对应的数值类型，其中BigDecimal专门用于金额，避免浮点精度问题。response.sendRedirect用的是重定向，地址栏会变，避免用户刷新页面时重复提交订单；而forward是请求转发，地址栏不变，常用于把错误信息带回表单页面。

接下来看Service层的addOrder方法，这是整个流程里最有含金量的一层：

public boolean addOrder(Order order) { Connection conn = null; try { conn = DBHelper.getConnection(); conn.setAutoCommit(false); OrderDao orderDao = new OrderDaoImpl(); int orderId = orderDao.insertOrder(conn, order); for (OrderDetail detail : order.getDetails()) { detail.setOrderId(orderId); orderDao.insertOrderDetail(conn, detail); } conn.commit(); return true; } catch (Exception e) { if (conn != null) { try { conn.rollback(); } catch (SQLException ex) { e.printStackTrace(); } } e.printStackTrace(); return false; } finally { DBHelper.close(conn); } }

核心是做了一次手写事务：setAutoCommit(false)之后连续插入订单主表和详情表，全部成功才commit()，任何一个环节异常就rollback()。为什么一定要有这一步？因为一个订单对应多条商品详情，如果主表插入成功而详情表插入失败，就会产生一个“没有明细的孤儿订单”数据，这在数据库里是脏数据的典型。你把这个逻辑讲清楚，老师基本不会再怀疑你不懂事务。

DAO层反而没什么好讲的，就是JDBC的PreparedStatement加参数绑定、执行executeUpdate()的固定套路。整个链路讲下来，你已经把“表现层→控制层→业务层→持久层”四层都说清楚了，这才是一个95分课设该有的理解深度。

4. 把95分做到99分：订单状态机与库存扣减的正确写法

4.1 状态机：为什么用int存状态而不是字符串

大量课设项目在订单表里加一个status字段，通用写法是varchar(20)，存“未付款”“已付款”“已发货”“已完成”这种中文字符串。这种写法在答辩时被问到“如果项目扩展成多种订单状态，你的字符串比较怎么处理”，很容易卡壳。

项目里的orders表如果你发现status字段是tinyint或int类型，说明作者当初设计时考虑了扩展性。用数字存状态的好处是：数据库层面存储空间小、索引效率高、比较运算比字符串匹配快；Java代码层面可直接与枚举对应，不会出现字符串大小写错误。常见的映射规则如下：

如果你手里的源码确实用的是字符串状态，升级成int型有两种路线：一种是把数据库字段改成tinyint，同时把Java代码里所有比较状态的地方从"已发货".equals(order.getStatus())改成order.getStatus() == 2；另一种是不动数据库，在Java里加一个OrderStatus枚举来做映射。第二种改法对数据库是零侵入，相对稳妥：

public enum OrderStatus { PENDING_PAYMENT(0, "待付款"), PENDING_SHIPMENT(1, "待发货"), SHIPPED(2, "已发货"), COMPLETED(3, "已完成"), CANCELED(4, "已取消"); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code = code; this.desc = desc; } public static OrderStatus fromCode(int code) { for (OrderStatus status : values()) { if (status.code == code) { return status; } } throw new IllegalArgumentException("未知订单状态：" + code); } }

这段代码放在entity包里，页面显示状态时用OrderStatus.fromCode(order.getStatus()).getDesc()替代直接读数字，以后状态变更只需要在枚举里加一个常量。它不增加任何依赖，但答辩时讲“用枚举抽象订单状态，避免魔法数字散落在业务代码里”，这句话比写上十行注释都有说服力。

4.2 库存扣减：乐观锁和并发下的脏数据问题

超市订单系统的另一个高分点是库存扣减逻辑。低质量版本的写法是：

SELECT stock FROM product WHERE product_id = ?; -- 在Java里判断 stock >= quantity -- 然后执行 UPDATE

这个流程在演示单用户操作时没有任何问题，但答辩老师只要问一句“两个用户同时下单，库存不够怎么办”，你就会意识到查询和更新之间不是一个原子操作，很可能两个请求都读到库存在5，同时扣到了0，但销量被记了两笔。这个问题在并发场景下的专业术语叫超卖。

解决超卖最简洁的方式是使用原子更新，让“条件判断+库存扣减”在一条SQL里完成：

UPDATE product SET stock = stock - ? WHERE product_id = ? AND stock >= ?;

执行这条语句后，影响行数是1表示扣减成功，0表示库存不足、下单失败。关键点在于stock >= ?这个条件让数据库在更新前自带了校验，两条并发SQL同时到达时，InnoDB的行锁会保证一次只有一个事务能成功，天然杜绝了超卖。

在Java代码里，DAO层返回受影响的记录数，Service层据此判断是否继续走订单流程即可：

public boolean deductStock(int productId, int quantity) { String sql = "UPDATE product SET stock = stock - ? WHERE product_id = ? AND stock >= ?"; int rows = jdbcTemplate.update(sql, quantity, productId, quantity); return rows > 0; }

这里要注意的是，stock字段在数据库里必须是INT UNSIGNED或BIGINT，不能是VARCHAR存数字，否则stock - ?会被隐式转换，完全失去性能与正确性。

再顺带提一个加分辅助：为orders表的order_no字段加唯一索引，生成订单号时用雪花ID或时间戳+随机数，这样同一用户重复点击提交按钮时，第二条重复订单会因为唯一索引冲突而失败，这也比在Java代码里做“是否重复提交”的判断更可靠。

4.3 加分项：多表联查与分页查询的优化写法

很多课设的订单列表页面会对三张表做联查：订单表、用户表、供应商表。初级写法是直接在JSP页面里写嵌套循环调DAO，每显示一行订单就查一次供应商名称，这种N+1查询在数据量只有几十条时不明显，但把数据填充到500条以上，页面加载会肉眼可见地变慢，是一个可以直接看出来的性能短板。

正确的做法是在DAO里一次联查取出所有展示字段：

SELECT o.id, o.order_no, o.total_amount, o.status, o.create_time, u.real_name AS consumer_name, s.sup_name AS supplier_name FROM orders o LEFT JOIN sys_user u ON o.user_id = u.id LEFT JOIN supplier s ON o.supplier_id = s.id ORDER BY o.create_time DESC LIMIT ?, ?;

这里有两个细节：一是表连接字段最好有索引，否则联表查询会退化成全表扫描；二是在SQL语句的LIMIT参数中直接传页码，而不是先把所有数据查出来再在Java里截取。传参时起始行是(currentPage - 1) * pageSize，如果用的是MySQL的LIMIT，注意页面的1号页对应的其实是偏移量0，这是新手最容易在翻页bug上翻车的地方。

分页的整体逻辑可以用一条COUNT(*)查询获取总条数，再算总页数：

int totalRows = orderDao.countAll(); // SELECT COUNT(*) FROM orders int pageSize = 10; int totalPages = (int) Math.ceil(totalRows * 1.0 / pageSize); int currentPage = Math.min(requestedPage, totalPages); int offset = (currentPage - 1) * pageSize; List<Order> orders = orderDao.findPage(offset, pageSize);

把count查询和findPage分开，不放在一个方法里，是因为COUNT和SELECT WHERE的条件往往不同，混在一起会让SQL变得不好维护。有些同学只用PageHelper插件做物理分页，我还是建议课设里自己写LIMIT ? , ?，这样答辩时能解释清楚底层原理，而不是只能说“我用了一个开源插件”。

5. 课设答辩避坑指南：预编译、乱码、SQL注入与演示翻车

5.1 SQL注入：老师必问，用预编译一句话堵住追问

答辩时“你的登录功能有没有考虑SQL注入”是出现频率最高的问题。不少课设的登录DAO是这么写的：

String sql = "SELECT * FROM sys_user WHERE user_name = '" + username + "' AND password = '" + password + "'"; Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(sql);

这段代码只要输入用户名' OR '1'='1、密码随便填，拼接出来的SQL永远满足条件，直接登录成功。无论项目其他部分做得有多好，这一处就足够把分数压到90以下。

真正的防注入写法是用PreparedStatement做预编译：

String sql = "SELECT * FROM sys_user WHERE user_name = ? AND password = ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password); ResultSet rs = ps.executeQuery();

原理方面，PreparedStatement会将SQL语句的结构与参数分开，参数中的单引号'、双引号"等特殊字符全部交给数据库的预编译机制处理，不再参与SQL语法解析。这里可以顺带提一句，即便只是普通课设项目，也建议检查一下整个项目的DAO层是不是统一使用了PreparedStatement，用字符拼接的地方按照规范改掉。

5.2 中文乱码：从请求到响应的完整链路排查

乱码问题会在三个位置分别发生：请求参数读入时、数据库读写时、页面响应时。只修其中一处是没用的，必须完整地走一遍链路。

请求乱码：POST请求，要在Servlet的第一行写request.setCharacterEncoding("UTF-8")，原理是告诉容器用UTF-8解码请求体。GET方式提交的乱码，问题在tomcat默认会以ISO-8859-1解码URL参数，需要在server.xml的<Connector>上配置URIEncoding="UTF-8"，或是Java代码里手动按ISO-8859-1读、按UTF-8转码。

数据库乱码：即使URL带了characterEncoding=UTF-8，MySQL服务端直接是latin1编码，读取时照样乱。前面2.3节已经说过，执行SHOW VARIABLES LIKE 'character%'检查character_set_server是校验这一步的关键。如果你改不了MySQL全局配置，还有一个局部方案——在获取连接后加一句SET NAMES utf8mb4：

PreparedStatement ps = conn.prepareStatement("SET NAMES utf8mb4"); ps.execute();

这句话相当于让当前连接的客户端、连接、结果集三类字符集全部切到utf8mb4，效果和修改全局配置一致，并不影响其他项目的连接。

响应乱码：JSP页面头部的contentType和JSP页面本身的文件编码必须保持一致。很多老项目用GBK，一份文件里两种编码混写就会导致输出到浏览器时是半个乱码字符。稳妥起见，把每张JSP页面的这两行统一成UTF-8：

<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

还有一层容易被忽略的是响应头编码：如果Servlet里直接response.getWriter().write(...)往浏览器输出少量字符串，可以补一句response.setCharacterEncoding("UTF-8")。保证三个位置都一致后，乱码才能从根上解决。在实际项目中，经常出现只改一处就以为修好了，换一台机器复现时乱码又出现的情况，所以我把这三处完整列在这里，你可以当作业直接把项目里所有Servlet头部和JSP头部都检查一遍。

5.3 演示当天必翻车的几件事：从Tomcat端口到Excel导出

演示翻车是最不划算的减分项。据我带课设的经验，90%的演示失败都不是因为代码缺陷，而是环境性意外。以下几条是高频事故及其应对方法。

现象一：Tomcat启动时提示Port 8080 was already in use。
原因：上次启动没有完整关闭，Java进程还占着端口，或者是其他服务占用了8080。
解决：不要直接改Tomcat端口，先定位占用进程。

netstat -ano | findstr 8080 taskkill /PID 进程号 /F

改成其他端口（如8081）虽然在演示时能用，但项目里所有写死8080的跳转链接会全部失效，得不偿失。

现象二：登录成功后跳转列表页，页面样式全部丢失。
原因：静态资源路径在登录页和列表页不同，用了绝对路径/css/style.css而非动态上下文路径。
解决：JSP页面里所有引用改成${pageContext.request.contextPath}/css/style.css：

<link rel="stylesheet" href="${pageContext.request.contextPath}/css/style.css">

request.contextPath不管是/supermarket还是/，都能动态拼出根路径，地址栏URL无论嵌套多深都不会错。

现象三：演示时新增订单成功，但列表页没有出现这条数据。
原因：多半是提交后跳转的是缓存页面，或者redirect路径写错了，跳到了旧列表。
解决：演示前先强制刷新列表页确认数据可见，同时把浏览器缓存关掉。关键检查点是重定向路径是否带了request.getContextPath()前缀，比如response.sendRedirect(request.getContextPath() + "/order/list")而不是写死/order/list，否则部署到非根路径时必然404。

我带的项目里还遇到过一种特殊情况：某个学生用的阿里云服务器做演示，MySQL服务是从WAMP或宝塔面板里独立启动的，但项目代码在IDEA里连的是localhost，远程访问还需要改URL里的localhost为公网IP或内网IP，这个坑容易被当成代码问题排查，白白浪费半小时。

6. 提交前最后一天：用一份自测清单稳住成绩下限

离提交还剩一天时，再泛泛地看代码已经意义不大了，你需要按下面的清单走一遍完整流程。这不是让你去测每一个功能是否做得多漂亮，而是确保“开箱就能跑”这条底线不破。

第一步，拿一台没有装过任何环境的电脑（或是把系统环境变量里的JDK/MySQL全部临时移除），按你的部署文档从零开始装一遍JDK、MySQL、Tomcat，然后把项目跑起来。如果这台机器能成功跑到登录页，说明你的文档没坑人；如果中途报错，把报错信息和解决步骤更新到README里。这一步做完，不光是稳住了自己，更是在为答辩加分——你成了这门课里少有的“交付级”课设。

第二步，用浏览器无痕模式走一遍核心用户路径：登录→新增订单→退出→重新登录→查看订单详情。无痕模式能清掉所有缓存和Cookie，杜绝了“因为浏览器缓存了旧页面所以看着功能正常”的假象。

第三步，打开数据库客户端，检查所有业务表是不是有正文里提到的新增测试数据。如果测试数据带有明显的随意性（比如商品名叫“测试”），赶紧改成正向示例数据，顺便多造几十条订单数据，让分页效果在演示时更直观。

这些年看过太多学生倒在“代码能跑”和“演示能看”之间的这条缝里。我的血泪教训是：永远不要在现场答辩时第一次执行“新增订单”这个操作，因为哪怕概率只有百分之一的数据库连接超时都能让你大脑空白。提前预演三遍，把每一步操作形成肌肉记忆，比再读十篇架构文章都有用。

走完这三步，你就可以踏实提交了。这套检查清单不止适用于超市订单系统，换了任何一个Javaweb课设，思路都完全复用。希望帮到你。

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