Java家用电器销售网站源码部署全攻略：从Tomcat到数据库实战

简介：一份基于Java/JSP的家用电器销售网站完整项目资源包，适合正在准备Java毕业设计、课程设计或程序设计实践的学生，帮助解决从系统设计、代码编写到文档撰写和答辩展示的完整需求。系统采用JSP动态网页技术，以Java为主要开发语言，搭配MySQL后台数据库，划分为前台、用户端和管理员端三条业务线：前台首页包含商品信息、商品资讯、留言反馈、购物车和后台跳转入口；注册用户可管理个人中心、订单评价、我的收藏和订单；管理员则围绕用户、商品分类、品牌、商品信息、订单评价、留言板、系统及订单进行综合管理，覆盖了家电销售网站从商品展示、下单购买到订单评价的基本闭环。压缩包约119.19MB，内含完整源码、说明文档、LW、PPT和演示视频，分别用于本地部署调试、设计说明撰写、答辩展示和运行效果参考。目前已有80人学习，需要完整项目方案或快速上手电商类JavaWeb开发的学习者可以直接使用。

1. 家用电器销售网站Java源码包：跑通它比看懂PPT重要

你手里的这份“java项目之家用电器销售网站（完整源码+说明文档+LW+PPT+演示视频）.zip”，是Java课程设计/毕业设计最常见的整包交付物。很多人下载后先解压看PPT，结果到答辩前一天才意识到项目根本没跑起来。真正该做的第一件事，是把这堆文件按“还原创作者开发顺序”的方式排一遍。这个压缩包一般包含一套完整的Java Web家用电器销售网站源码：用户注册登录、商品分类展示、购物车下订单、后台管理商品与订单，外加LW论文/设计文档、答辩PPT和演示视频。对正在做Java课设/毕设的人来说，它是一套可复现的骨架；对想快速熟悉Java Web流程的开发者，它是少见的带完整说明文档的实战样本。下面按“先跑通，再拆功能，后避坑，最后验证”的顺序，把整条落地路径讲透。

2. 从zip到Tomcat：先给文件分类，再匹配JDK与MySQL

拿到zip的第一件不该做的事，是双击打开PPT。第一件该做的事，是把它解压到一个纯英文路径。Tomcat对中文路径不是完全不能用，但出现莫名404、静态资源加载不出来时，路径里的中文往往是最先被怀疑的元凶。实际工作中我习惯建一个 C:/workspace-java/appliance 目录，把压缩包放进去解压。用Git Bash下的unzip或者任意图形化解压工具都行，关键是目录名不要出现空格和中文。

# 建一个不含中文和空格的纯英文工作目录 mkdir -p C:/workspace-java/appliance cd C:/workspace-java unzip java项目之家用电器销售网站（完整源码+说明文档+LW+PPT+演示视频）.zip ls -l C:/workspace-java/appliance

命令里的 -p 表示中间目录不存在时一并创建；ls -l 用于解压后立刻核对文件是不是被解压到了预期目录。很多Windows用户在这里踩坑：解压工具默认会把zip文件名再包一层目录，导致后面的路径变成 appliance/appliance/...，本地跑的时候不致命，但照着文档敲IDEA部署路径时会找不到Web根目录。打开一级目录后，先按文件类型分四类。

这个分类看起来简单，但决定你接下来信谁：跑程序只看源码和.sql；写报告才看说明文档和LW；PPT和演示视频是验收参照。LW在不同课设包里可能是“论文”的缩写，也可能是“设计说明书”，但作用都一样，解释“为什么这样设计”。如果你指望它完全对应源码，后面多半会对不上。

2.1 解压后先分四类文件：源码、数据库脚本、说明文档、答辩材料

把文件分好类的好处是，你不容易把.sql当附件忽略。很多课设包把数据库脚本藏在 db/ 或 sql/ 目录里，不仔细找根本看不见。没有.sql，你只能自己手写建表语句，而家电销售网站最少也有五张表，手写不难，但字段和源码对不上才是真正的麻烦。我一般会先打开.sql文件，确认它是纯建表语句还是包含INSERT测试数据。包含INSERT数据对演示很重要，因为首页商品列表如果为空，购物车和订单流程根本走不起来。

如果是Maven工程，源码里应该有 src/main/java 和 src/main/webapp，外加 pom.xml；如果是早期Eclipse工程，可能直接是 src/ + WebContent/。两种结构都能跑，但导入IDEA或Eclipse的方式不同。老项目常见做法是后者，这时要在项目配置里把 WebContent 或 WebRoot 指定为Web资源目录，否则启动Tomcat后访问不到JSP。这个点会在后面避坑章节展开，先在这里留个记号。

2.2 JDK、Tomcat、MySQL版本选型：课设项目不用追新

这类Java Web课设包大多诞生在JDK 8时代，因此最稳的组合是JDK 8、Tomcat 8.5、MySQL 5.7。如果手头只有JDK 8的zip包而不是安装版，配置JAVA_HOME时要自己写环境变量，很多教程会把zip版和安装版混着讲。其实zip版解压后，只需把JAVA_HOME指向解压目录，再在PATH里追加 JAVA_HOME/bin 即可。

# 临时指定JDK8环境，当前终端窗口有效 export JAVA_HOME=/c/software/jdk8u202 export PATH=$JAVA_HOME/bin:$PATH java -version

export 是临时设置，重开终端会失效；更标准做法是在系统环境变量里新增 JAVA_HOME，再把jdk8的bin插到PATH最前面。注意如果电脑上装了高版本JDK，java -version 返回的却不是你想要的版本，通常是因为系统PATH里高版本bin排在了更前面，调整顺序即可。JDK版本之所以挑剔，是因为老代码里的JSP依赖 javax.servlet，而Tomcat 10之后把包名换成了 jakarta.servlet，老项目直接用Tomcat 10会编译失败。反过来用JDK 17跑老JSP项目，可能连EL表达式都会因为模块限制报错。

MySQL版本的影响主要在JDBC驱动和连接串。MySQL 5.7下驱动类名是 com.mysql.jdbc.Driver，MySQL 8.0下要改成 com.mysql.cj.jdbc.Driver，并且连接串必须带 serverTimezone=Asia/Shanghai，否则启动时会报时区错误。如果项目lib里放的是旧驱动，连MySQL 8.0会直接报“Cannot create connection”，解决方法是把驱动jar换成 mysql-connector-java 8.0.3x 或更高版本，同时改连接串。一个参数不要小看，这一条能卡住大多数人。

2.3 导入数据库脚本与修改连接串：让项目找到数据库

找到.sql后，第一个动作是先建库。通用做法是打开命令行客户端执行下面三条命令：

# 创建数据库并统一字符集 mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS appliance_sales DEFAULT CHARACTER SET utf8mb4;" # 导入建表与初始数据 mysql -u root -p appliance_sales < db/appliance_sales.sql # 验证表是否导入成功 mysql -u root -p -e "USE appliance_sales; SHOW TABLES;"

第一条命令中的 -e 表示执行完语句就退出；DEFAULT CHARACTER SET utf8mb4 保证商品名称里的特殊符号不会变成问号。第二条命令把.sql里的SQL导入到 appliance_sales 库，注意这里是 < 重定向而不是 -e。第三条SHOW TABLES用于验证导入结果，正常能看到 user、goods、category、cart、orders 这类表。如果.sql文件里自己带了 USE 别的库名，导入后表会进错库，你需要用文本编辑器把脚本开头的 USE 改成目标库名，或者干脆删掉那一行。

接下来修改源码里的数据库连接信息。这类项目通常把配置放在 src 下的 db.properties 或 jdbc.properties，也有少数直接写在 JDBCUtil.java 里。改连接串时注意保留 useUnicode=true&characterEncoding=utf8 这两项，不然中文乱码跑不掉。

# JDBC配置，注意MySQL8.0驱动类名有变化 jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/appliance_sales?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=123456

如果连接的是MySQL 8.0，第一行驱动类名要改成 com.mysql.cj.jdbc.Driver；serverTimezone参数在高版本MySQL是必填项，否则启动报时区识别错误。与此同时，检查项目lib里有没有对应版本的驱动jar。改完配置别急着启动，先确认Tomcat端口和项目上下文路径。端口在 conf/server.xml 里默认8080，上下文路径要看部署时的war包名，或者IDEA里Artifact的Deployment名称一致，最后访问 http://localhost:8080/appliance/ 才是这个Java家用电器销售网站的首页。

注意：MySQL 8.0的驱动类名必须换成 com.mysql.cj.jdbc.Driver，否则即使连接串正确，Class.forName也加载不到驱动，启动日志会直接报“ClassNotFoundException”。

3. 功能拆解：用户登录、商品浏览、购物车、订单怎么串起来

先想清楚一条主链路：用户注册/登录后浏览家用电器列表，把某台冰箱加入购物车，到购物车页面修改数量并结算，提交后生成一个“待付款”订单，管理员在后台看到订单后修改状态为“已付款/已发货”，用户确认收货后订单变成“已签收”。这套流程几乎是所有课设项目的共同骨架，区别只在用JSP+Servlet，还是用Spring + SpringMVC + MyBatis。如果你拿到的是SSM工程，代码结构会更清晰，但核心仍然绕不开“控制器处理请求→Service处理业务→Mapper读写MySQL”三层。把这个拆明白，改需求才有下手的地方。

3.1 用户端和管理员端的请求路径与Servlet职责

这类项目里最常见的请求路径设计是：用户端和管理员端各用一组前缀。用户端有 /login、/register、/goods/list、/goods/detail、/cart/add、/cart/remove、/order/create；管理员端有 /admin/login、/admin/goods/list、/admin/goods/save、/admin/order/list、/admin/order/update。如果你用Eclipse老工程，这些路径背后通常是一个个Servlet类；如果是Maven的SSM，则对应Controller类上的 @RequestMapping 注解。

一个登录Servlet的典型写法是下面这个样子：

@WebServlet("/login") public class LoginServlet extends HttpServlet { @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String username = req.getParameter("username"); String password = req.getParameter("password"); User user = userService.login(username, password); if (user != null) { // 登录成功，把用户对象放入session req.getSession().setAttribute("loginUser", user); resp.sendRedirect(req.getContextPath() + "/goods/list"); } else { req.setAttribute("errorMsg", "用户名或密码错误"); // 服务器内部转发，留在登录页面 req.getRequestDispatcher("/login.jsp").forward(req, resp); } } }

代码里的 sendRedirect 是重定向，能让浏览器地址栏变成 /goods/list；forward 是服务器内部转发，登录失败时留在login.jsp页面并把错误信息带到页面显示。看似细节，但答辩时经常被问：两者区别是什么。如果你在项目里看到这样写的登录逻辑，基本就能确认作者是按经典Servlet规范写的。另一方面，管理员和普通用户的会话权限通常只靠session里是否存了 loginUser 或 adminUser 来判断，Spring版本可能在Interceptor或Filter里统一拦。自己复用时，建议在所有需要用户状态的页面上加一个过滤器，而不是在JSP里散落判断代码。

3.2 数据库表设计：电器表要冗余字段，订单表要快照

家电销售网站最少需要 user、category、goods、cart、orders 五张表。category管理冰箱、洗衣机、空调这类大分类，goods通过category_id外键关联分类。一个容易被忽略的字段是 goods.image，课程设计里商品图片往往是相对路径，源码包里会有一批以数字命名的图片文件放在web下的images目录。如果图片丢了，页面会裂，所以解压后不要动images目录。

商品表和订单表的核心字段可以这样建：

-- 商品表，分类外键关联category表 CREATE TABLE goods ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL, name VARCHAR(128) NOT NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, image VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_category (category_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 订单表，保存下单时的商品名称与价格快照 CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, user_id INT NOT NULL, goods_id INT NOT NULL, goods_name VARCHAR(128) NOT NULL, price DECIMAL(10,2) NOT NULL, buy_count INT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0待付款 1已付款 2已发货 3已签收', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user (user_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

orders表里有 goods_name 和 price 两个冗余字段，这是有意为之。下单时把商品名称和成交价格快照保存，后续管理员如果改了商品价格，历史订单仍然显示用户下单时的价格。如果只存goods_id去联查商品表，价格一变，历史订单跟着变，业务上是不正确的。这个细节写进LW里是加分项，答辩时能表现出你明白“为什么订单表要快照”而不是只会建表。另外 order_no 可以用时间戳加随机数生成，避免用户在下单接口被重放时产生完全相同的记录。很多课设项目不建 order_no，但电商系统里订单号是业务主键的替代方案，值得补上。如果你习惯用MyBatis-Plus这类工具根据实体类注解自动生成建表SQL，快速原型很爽，但课设包大多还是手写SQL更直观，也更能展示数据库功底。

3.3 购物车实现：Session容器还是数据库表，答辩前必须能说清

最常见的课设做法是购物车放在Session里，用 Map<Integer, Integer> 存商品ID和数量，而不是落一张cart表。这么做的好处是免登录也能加购，缺点是Session一失效购物车就没了，所以很多项目还会做一个合并操作：登录时把Session购物车写入数据库表或Cookie。如果你拿到的是更简单的一版，它可能连cart表都没有。不要嫌弃这种实现，它能让演示时少填一张表，但答辩时一定会被追问“刷新页面为什么还在”。所以你要么把购物车持久化，要么至少能说清Session生命周期。

Session购物车的核心代码：

// 从session中取出购物车Map，商品ID -> 购买数量 @SuppressWarnings("unchecked") Map<Integer, Integer> cart = (Map<Integer, Integer>) session.getAttribute("cart"); if (cart == null) { cart = new HashMap<>(); session.setAttribute("cart", cart); } // 如果商品已在购物车中，数量加1；否则放入数量1 cart.merge(goodsId, 1, Integer::sum);

第一行从Session里取出上次存好的购物车Map，取不到就新建一个。最后一行 cart.merge(goodsId, 1, Integer::sum) 是Java 8的Map方法：如果商品ID已存在，数量加1；如果不存在，放入数量1。sum方法的作用是累加。这段代码虽然简单，但它把“同一种商品多次加入购物车”这个问题解决了。也正因为它本质是内存操作，分布式部署时Session会被拆分，必须改用Redis或数据库。答辩时主动说出这句话，会明显拉开和照着PPT念的同学的距离。

4. 关键实现：商品搜索、分页列表与订单状态机

功能拆完，进入三个容易被老师追问的点：商品搜索怎么写、列表分页怎么算、订单状态怎么流转。很多课设源码对这三个地方处理得非常潦草，但你照着下面改一遍，代码能力就能体现出来。同时这些也是Java面试里高频的Web基础，改完这一轮再看“java面试题”，会发现不再是死记硬背。

4.1 用LIKE做电器名称搜索：PreparedStatement防注入与编码一致

商品搜索最常见的实现是SQL里的LIKE模糊查询：

// 按商品名称模糊查询，排序交给数据库 String sql = "SELECT * FROM goods WHERE name LIKE ? ORDER BY id DESC"; List<Object> params = new ArrayList<>(); params.add("%" + keyword + "%"); List<Goods> list = goodsDao.find(sql, params);

在JDBC里，占位符 ? 不会被 % 包围，所以keyword前后要手动拼上“%”。关键是不要用字符串拼接的方式把keyword直接嵌入SQL，否则用户输入一个 “%' OR '1'='1” 就能把所有商品导出来，这是课设项目最容易被老师盯上的安全问题。使用PreparedStatement时，setString(1, "%" + keyword + "%") 传入即可。排序也尽量不要在Java里用冒泡排序、比较器之类的做法，数据库的ORDER BY简单可靠，内存排序数据量大一点就亏。如果搜索结果为空，页面要给出“没有找到匹配的家用电器”的提示，有些项目直接渲染空List导致页面空指针，可以在Service层返回空列表，JSP里用 <c:if test="${not empty list}"> 判断。

中文搜索出现空结果，常见原因不是SQL错，而是数据库连接串和JSP编码不一致。连接串没带 characterEncoding=utf8 时，keyword到MySQL已经被转成其他字符集，SQL查询自然永远返回空。先查连接串，再查JSP页面顶部的 <%@ page contentType="text/html; charset=utf-8" %>。另外要注意，如果用户搜索的词里本身包含 % 或 _，LIKE会把它们当成通配符。想精确匹配“50%”这类词，可以用 ESCAPE 定义转义符：WHERE name LIKE ? ESCAPE '/'，再把参数里用户的 % 替换成 /%。大多数课设不会做到这一层，但面试里被问过之后再做一次，记忆会很深。

4.2 分页查询的pageBean计算：LIMIT参数与总页数边界

分页代码在课程设计里通常长这样：

int pageSize = 8; int pageNo = 1; String pageNoParam = request.getParameter("pageNo"); if (pageNoParam != null && !pageNoParam.isEmpty()) { pageNo = Integer.parseInt(pageNoParam); } // 计算总页数，向上取整 int totalCount = goodsDao.count(keyword, categoryId); int totalPage = (totalCount + pageSize - 1) / pageSize; if (pageNo > totalPage) pageNo = totalPage; // offset从0开始，第二页的offset是(pageNo-1)*pageSize List<Goods> list = goodsDao.findPage(keyword, categoryId, (pageNo - 1) * pageSize, pageSize);

totalPage 的计算公式是 (totalCount + pageSize - 1) / pageSize，标准的向上取整技巧。比如总数17、每页8，(17 + 8 - 1) / 8 = 3就是3页；如果你直接 totalCount / pageSize，得到2，最后一页的9条数据就永远显示不出来。findPage 最后两个参数是 LIMIT 的 offset 和 size，offset 从0开始，所以第二页 offset 是 (2-1)*8=8。这里有一个边界坑：pageNo 传成负数或超大数时，Integer.parseInt 会抛异常，或者查询出越界数据。更稳的写法是把解析包在 try/catch 里，非法入参直接当成1。

分页下一页和上一页的链接是这样拼的：/goods/list?pageNo=${current+1}&keyword=${keyword}。页码参数必须带关键词，否则翻到第二页时搜索条件失效。预览项目时，别只点“下一页”，还要带着搜索词翻页验证，很多项目在搜索状态下翻页会清空条件，这是答辩演示时很尴尬的bug。如果你拿到源码里没有count方法，分页查询也没办法算总页数，可以补一个SELECT COUNT(*) FROM goods WHERE name LIKE ?，这是分页功能的最小依赖。

4.3 订单状态流转：前置状态校验，别让页面按钮直接改状态

订单状态从0到3，必须按顺序流转：待付款→已付款→已发货→已签收。但是很多课设源码在管理员后台只做一个下拉框，直接 UPDATE 状态为任意值。真正可靠的做法是在更新前校验当前状态是前置状态：

// 只有当前状态等于currentStatus时，才允许更新到targetStatus public boolean updateStatus(int orderId, int userId, int currentStatus, int targetStatus) { String sql = "UPDATE orders SET status=? WHERE id=? AND user_id=? AND status=?"; Object[] params = { targetStatus, orderId, userId, currentStatus }; return jdbcTemplate.update(sql, params) == 1; }

注意 WHERE 条件里同时带上了 user_id 和 status。带上 user_id 是防止用户随便传订单号去改别人的订单；带上 status 是让数据库来保证只能从特定状态推进到下一个状态。比如用户点击“确认收货”时，targetStatus=3，currentStatus=2，如果订单已经被管理员改成3，这次UPDATE会匹配0行，返回false，避免状态回退。这比先SELECT再UPDATE更安全，因为两条语句之间如果并发修改，状态会被覆盖。

在JSP页面上，按钮显示也要和状态匹配。常见做法是 JSTL 的<c:if test="${order.status == 0}"> 显示“模拟支付”按钮 </c:if>，状态到2时才显示“确认收货”。很多课设项目在这里图省事，把发货和确认收货按钮全部渲染出来，导致用户能看到并点击本不该出现的按钮。展示不好看，更重要的是状态机形同虚设。如果是SSM工程，记得在Service层加上 @Transactional，保证更新订单状态和扣库存两个操作要么同时成功要么同时失败，否则会出现“订单已发货但库存没减”的不一致。

5. 避坑指南：从部署到答辩的五个典型翻车现场

这五个坑是Java Web课设项目里最高频的，我经手过的源码包十有八九会踩中。每条按现象、原因、解决三步说清，顺序也基本对应踩坑顺序：先部署，再编码，然后数据，最后论文和答辩。

5.1 现象：Tomcat启动成功但访问首页404

Tomcat能正常启动，浏览器访问 http://localhost:8080 也看得到默认首页，但输入项目路径就是404。原因通常是项目没有真正部署到Tomcat，或者部署时的上下文路径和你访问的不一致。如果你是直接把源码丢进IDEA再配置Tomcat，检查 Artifact 的 Deployment 里的 Application context 是不是 /appliance；如果是在Eclipse老项目里，检查项目属性里的 Web Context Root。另外，web.xml里配置的欢迎页是 index.jsp 或某个Servlet映射，如果页面本身没编译到输出目录，也会404。

解决：IDEA里打开 Run > Edit Configurations，看 Deployment 标签页，把 Application context 改成和访问路径一致；老Eclipse工程先重新编译，确认 WEB-INF/classes 下有 .class 文件再启动。一个比较隐蔽的坑是项目没被标记为Web项目，导致Tomcat部署不了，表现为明明看到project在列表里，启动日志却只有“None of the configured artifact...”没有实际加载。把项目按Web资源目录重新配置一遍即可。还有一个容易忽略的小问题：如果你把war包直接丢到Tomcat的webapps下，Tomcat会自动解压，但旧版本的项目备份可能占据了解压后的同名目录，导致新代码不生效，删除旧的解压目录再重启。

5.2 现象：商品列表中文全部变成问号

登录后商品列表显示“???”，但数据库里用命令行查询中文却正常。原因有三处可能：JSP页面编码、连接串字符集、MySQL表字符集。任何一个环节是latin1，中文就会乱。修复顺序是先看数据库表，执行 SHOW CREATE TABLE goods;，确认 CHARSET 不是 latin1；然后把连接串里的 characterEncoding=utf8 加回来；最后确保每个JSP开头都有<%@ page contentType="text/html; charset=UTF-8" %>。

注意MySQL 5.1之前的连接串写法可能只要 characterEncoding=utf8，而 utf8mb4 是4字节存储，能支持更多特殊字符。如果建表用 utf8mb4，连接串却写 utf8，查询中文没有影响，但插入某些emoji符号会被截断。简单做法是全部统一成 utf8mb4。如果项目用的老JDBC驱动不支持 utf8mb4，至少保证连接串和表字符集一致，不能一个utf8一个latin1。动手之前可以在MySQL客户端执行SET NAMES utf8mb4;先验证客户端显示是否正常，缩小排查范围。

5.3 现象：点击“加入购物车”报500

这个错最难受，因为常不打印业务日志。原因三种最常见：第一，购物车Map从Session取出后强转失败，Session里其实存的是别的类型；第二，goodsId从页面传到Servlet时参数名不匹配，导致 Integer.parseInt(null) 抛 NumberFormatException；第三，数据库里没有对应的商品ID，外键约束报错。现象都是500，但日志关键字不同。

解决：先看IDEA控制台完整异常栈。搜“NumberFormatException”就是参数类型问题，搜“Cannot cast”是Session强转问题，搜“foreign key constraint”就是外键问题。参数名问题去JSP里看表单name属性和Servlet的getParameter取值是否一致。一个土办法是直接在Servlet入口处写 System.out.println(request.getParameter("goodsId")); 先确认参数有没有进来。项目里如果配了log4j，尽量用logger.error打印，否则堆栈会被Tomcat日志吞掉，不好定位。

提示：排查500别在浏览器里盲刷，打开Tomcat的logs/localhost日志，按时间点找最近的Exception，效率高很多。

5.4 现象：PPT演示正常但演示视频无法播放

拿到源码包后想完整看一遍演示视频，结果Windows Media Player或PotPlayer打不开，或者只有声音没有画面。原因是课设视频经常被压缩成高码率MP4，或者编码使用H.265，而老版本播放器不支持。PPT文件也可能出现类似问题，用WPS打开高版本PPT有排版错乱。

解决：装一个VLC播放器，它能解码绝大多数格式；PPT尽量用Office或WPS的兼容模式。至于“演示视频里明明开着某个页面，而你的项目里找不到这个页面”的问题，放到下一节一起说。千万别把打不开视频当成小事，答辩前再看就来不及换播放器。

5.5 现象：说明文档/LW的架构图和实际源码对不上

这是课设源码包最经典的漏洞：LW写的是Spring Boot + MyBatis，zip里的源码还是JSP + Servlet。原因是作者把多年前的LW用在了新项目上，或者反过来。如果你照着LW的时序图讲项目，讲到一半发现代码里根本没有这个Service，就尴尬了。

解决：以源码和演示视频为准，LW只当参考。把LW当作“为什么这么设计”的背景，而不是“代码确实是这么写的”证据。拿到包没空重写文档时，就把LW里描述不存在的模块划掉，补上源码里真实存在的模块。答辩老师大概率是看你现场演示和项目代码，不会逐句对论文，但你能主动解释“这个功能在代码里对应哪个类”，比什么都强。

6. 验证技巧：用一条冒烟测试链路把这个销售网站讲圆

项目跑通只是及格，能从头到尾讲圆才是拿高分的前提。我建议你给自己定一条冒烟测试链路：注册新用户 → 登录 → 浏览“冰箱”分类 → 搜索“变频” → 把商品加入购物车 → 购物车数量加2 → 提交订单 → 后台管理员登录 → 将订单发货 → 用户端确认收货。整个过程最好用浏览器录屏或按顺序截图，这比看zip里自带的演示视频更能反映“你这个版本”的真实行为。

验证时可以配合一段命令行冒烟测试，但课设项目往往不是纯REST接口，所以不用强求：

# 登录并保持Cookie会话 curl -c cookies.txt -d "username=demo&password=123456" http://localhost:8080/appliance/user/login # 携带会话，把商品1加购2件 curl -b cookies.txt -d "goodsId=1&buyCount=2" http://localhost:8080/appliance/cart/add # 查看购物车 curl -b cookies.txt http://localhost:8080/appliance/cart/view

-c 和 -b cookies.txt 是为了让两次请求共享同一个Session。如果项目不依赖Cookie而是用URL重写，这个脚本就要改成手动拼接SessionID。即便curl跑不通，手工在浏览器里按F12打开Network面板，一样能观察到请求路径和参数。重点不是自动化，而是验证每一条链路的请求参数名称和页面跳转都正常。

执行完冒烟测试后，我习惯再做一件事：对照演示视频暂停的每一帧，在源码里找到对应的JSP或Controller。如果视频里点“加入购物车”后右上角数量变了，就去看Session里的购物车变量是不是在整个页面都用同一份；如果视频里订单有“确认收货”按钮，就去JSP里找那行 <c:if test>。这样做一次，你对这个项目的熟悉程度会超过只看源码的人。我的经验是：很多课设包的真实状态比PPT写的粗糙，但核心闭环只要通，剩下的边角自己补。带着这套验证结果去答辩，哪怕被问住，也能坦然说“这块我验证过，数据流是通的”。希望帮到你。

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