企业官网建设流程全解析

简介：百货中心供应链管理系统是一套基于JAVA技术构建的综合项目资料，覆盖供应商管理、库存控制、订单处理、物流配送和销售分析等核心业务，适合毕业设计开发者、JAVA初学者及零售企业信息化人员研读参考。资料包为rar压缩格式，共15个文件，大小约62.58MB，包含JAVA源码压缩包、SQL数据库初始化脚本、毕业设计说明书论文、两段项目部署与功能演示操作视频，以及10张系统关键页面与模块截图，可直观了解登录页、系统主页面、采购管理、合作公司管理、数据统计等界面的实际效果。目前已有501人学习，资料将源码、数据库、论文与视频四类材料整合在一起，读者可参照视频逐步完成环境搭建与项目启动，结合论文梳理模块划分和数据库表设计思路，借助SQL脚本快速建立初始数据环境，再基于现有源码进行业务扩展与二次开发，能够有效缩短供应链系统项目的理解与落地周期，同时为同类管理信息系统的设计提供可复用范本。

1. 百货中心供应链管理系统：一套能直接拿去答辩和上线的 JAVA 课程设计

如果你搜到这个标题，大概率是在做 Java 课程设计或毕业设计，手头需要一个「业务完整、代码能跑、论文能写、数据库不用从零建」的现成方案。百货中心供应链管理系统，本质上是一个典型的进销存 Plus 版本——它在传统商品管理之上，把采购、入库、库存、销售、供应商、结算这条链路串起来，比学生常见的「单表增删改查」高一个档次，又没到 ERP 那种需要懂财务和排产的程度。这套东西能解决的核心问题是：让你在两周内交付一个业务闭环完整、答辩时有得讲、代码结构能被老师挑不出大毛病的中型 Java Web 项目。

它的受众很明确：一是 Java 课程设计/毕设需要交源码和论文的在校生；二是想快速搭一套内部供应链管理原型的中小公司开发者。前者需要的是能跑通、能讲清楚、能改能扩展；后者需要的是代码规范、数据库设计合理、能换皮改成自己的业务。这套系统用的技术栈通常是 JSP/Servlet + SSM（Spring + SpringMVC + MyBatis）+ MySQL，配 Bootstrap 做前端，属于 Java 课程设计里最主流、最稳的一套组合。相比 Spring Boot 单体应用，它虽然重一点，但课程设计如果落到 JSP 上，评阅老师更熟悉，答辩也更容易往「传统企业级架构」方向讲出深度。

我先把话说在前面：这类源码包拿到手，第一件事不是看代码，而是把数据库脚本导进去、项目跑起来，先确认它能启动。很多同学卡在第一步 —— 数据库版本不兼容、JDK 版本不对、Tomcat 版本太新导致 JSP 解析报错。后面的章节我会把每一步的关键参数和踩坑点都列出来，你照着做，基本能在一个晚上把整套系统跑起来。

2. 需求拆解与表结构设计：先看懂供应链系统在管什么

2.1 从「进销存」到「供应链」：需求多了哪三块

百货中心的供应链管理系统，如果只做到商品增删改查、库存加减，那它就是个进销存，撑不起「供应链」这三个字。我在给企业做类似项目时，通常会把供应链系统拆成三个核心域：采购域、库存域、销售与结算域。采购域管的是「货怎么来」——从供应商询价、下采购单、到货验收、入库；库存域管的是「货在哪里、有多少」——库存台账、库存变动流水、预警；销售与结算域管的是「货怎么走、钱怎么算」——销售出库、退换货、供应商结算对账。

这套课程设计源码如果表设计是完整的，你会发现它一定包含这几张核心表：供应商表、商品表、采购单表、采购单明细表、入库单表、库存表、销售单表、销售单明细表、用户表、角色表。这些表之间的外键关系就是答辩时最好的讲解素材——老师一问「为什么要有采购单和采购单明细两张表而不是一张」，你就能答出主从表设计、一对多拆分、明细表冗余商品快照这三个理由。

表结构里还有个很容易被忽略但答辩高频的点：金额和数量的精度设计。商城系统的金额字段，课程设计里十有八九用double，但真实项目里这一栏必须是decimal(10,2)。double在累计求和、对账时会出现 0.1 + 0.2 不等于 0.3 的浮点误差——这是面试八股文里的老题，也是答辩时老师最爱追问的「你这里为什么用 BigDecimal 而不用 double」。你如果能在答辩时主动说出这一点，比背十道 Java 面试题都管用。

2.2 数据库脚本导入：SQL 文件跑不起来的三个真实原因

拿到数据库 sql 文件后，我一般不建议直接在 Navicat 里双击运行，而是先建一个空数据库，再选择这个空库执行 SQL 脚本。原因很简单：很多课程设计 SQL 脚本开头没有CREATE DATABASE语句，直接运行会报「未选择数据库」；反过来有些脚本带了CREATE DATABASE，在已有同名库时又会报错。最稳的做法是：

-- 第一步：创建数据库，指定字符集，避免中文乱码 CREATE DATABASE IF NOT EXISTS supply_chain DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE supply_chain; -- 导入完成后，验证核心表和初始数据是否齐全 SHOW TABLES; SELECT * FROM t_user LIMIT 5;

导入时最常见的坑不是语法错误，而是 MySQL 版本差异。课程设计的 SQL 脚本很多是在 MySQL 5.5/5.7 上导出的，如果你本机装的是 MySQL 8.0+，会遇到两个典型问题：一是utf8字符集在 8.0 里被废弃，虽然还能用但会告警；二是 8.0 的默认认证插件是caching_sha2_password，老版本的 JDBC 驱动连不上。解决方式是：数据库用utf8mb4，JDBC 驱动用mysql-connector-java 8.0.x，连接字符串里加上useSSL=false&serverTimezone=Asia/Shanghai。这三个参数不配好，项目启动报「Public Key Retrieval is not allowed」或时区异常是必然的。

导入后一定要查两张表的初始化数据：管理员账号表和基础参数表。课程设计通常会内置admin/123456之类的账号，但如果脚本里只有表结构没有初始数据，你登录页面会一直被拒。我自己踩过的坑是：某次导入后菜单能打开但登录永远提示密码错误，排查了半天，最后发现是 SQL 脚本里管理员密码存的是明文，但代码里登录校验用的是 MD5 加密后再比对。

2.3 商品与库存的核心字段：设计表的时候就要埋的扩展点

供应链管理系统答辩时，老师最爱问的一类问题是「你这个表设计如果遇到 XX 业务怎么改」。比如：商品表里如果只有price一个价格字段，遇到促销价、会员价、批发价就要改表；库存表如果只有quantity没有locked_quantity，遇到下单锁定库存就无法实现。课程设计的代码不要求你把这些全做出来，但表设计里可以先埋字段，答辩时说「我预留了扩展字段」，比临时改代码体面得多。

一个比较合理的商品表核心字段设计是：id, category_id, product_code, product_name, spec, unit, purchase_price, sale_price, warning_stock, stock, status, create_time, update_time。这里purchase_price和sale_price分开是必须的——供应链系统里采购价和销售价是两条线，混在一起的话，结算时就要靠拍脑袋了。warning_stock是库存预警阈值，低于这个值就在首页弹提示或者标红，这是供应链系统里最容易做出视觉效果、也最好讲的功能点。

库存表建议单独建一张，而不是把库存数量直接挂在商品表上。原因是为了记录库存变动流水——每次入库、出库、盘点都往t_stock_log里插一条记录，这样「这个月的库存是怎么从 1000 变成 800 的」就能追溯。这个设计在答辩时非常加分，因为大多数课程设计只做了增删改查，没做操作日志和流水追溯，你做了就是亮点。

3. 把源码跑起来：JAVA 环境、Tomcat 部署与数据库连接的参数清单

3.1 环境版本对照表：别让 JDK 和 Tomcat 打架

这套系统的源码如果是基于 SSM 或 JSP + Servlet 写的，它对运行环境有固定的版本要求。我在配置这类项目时，会遵循一个保守原则：不追求最新版，只追求「这套代码当年写的时候用的是什么版本」。版本不匹配的表现非常玄学——代码看着完全没问题，启动就是报ClassNotFoundException或者 JSP 编译错误。

以下是我跑这类课程设计项目的标准环境配置，你可以直接照抄：

Tomcat 和 JDK 的配对有个硬规律：Tomcat 9.0 要求 JDK 8 及以上，Tomcat 10 则是 Jakarta EE 的命名空间变更，老项目直接跑必挂——因为原来的javax.servlet包变成了jakarta.servlet，代码里全是红叉。如果你下载的源码包是几年前的项目，务必用 Tomcat 8.5 或 9.0，别用 Tomcat 10。

3.2 在 IDEA 里配置 Tomcat 的完整步骤与参数

把源码导入 IDEA 后，不要急着点运行按钮。先确认三件事：项目是否被识别为 Maven 项目（右侧 Maven 面板能看到依赖列表）、JDK 是否切换成 1.8、数据库连接配置是否指向本机。如果 pom.xml 里的依赖下载缓慢或失败，在 maven 的 settings.xml 里加阿里云镜像：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

配置 Tomcat 运行时，IDEA 里有一个高频坑：On Update和On Frame Deactivation两个下拉框必须设置成Update resources，否则你改了 JSP 或者静态资源后，刷新浏览器看不到变化，非得重启 Tomcat。这在调试前端页面时极其影响效率——我见过不少同学改完代码重启一次，三分钟一次的节奏改一下午，时间全耗在启动上了。

数据库连接配置通常在jdbc.properties或db.properties里，核心配置如下：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/supply_chain?useSSL=false&useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true jdbc.username=root jdbc.password=你的数据库密码

这里的serverTimezone=Asia/Shanghai必须加，否则 MySQL 8.0 会报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。allowPublicKeyRetrieval=true是 MySQL 8.0 配合caching_sha2_password认证插件时的必要参数，漏掉会报Public Key Retrieval is not allowed。这两个错误在课程设计项目里出现的频率极高，我几乎每次帮人排查都能看到至少其中一个。

3.3 启动失败黑匣子：从日志里三分钟定位问题

Tomcat 启动失败时，控制台日志会是一大坨红色报错，新手容易慌。我的习惯是只看最前面的Caused by:或者Exception原始堆栈——Maven 或 Spring 框架的包装异常往往会套十几层，真正的原因藏在一开始的几行里。最常见的三类启动失败长这样：

第一类：ClassNotFoundException: org.springframework.web.context.ContextLoaderListener。原因是 Spring 相关的 jar 没有部署到 Tomcat 的 lib 目录，或者依赖没有下载完整。解决方式是在 IDEA 的 Project Structure 里检查 Artifacts 的 Output Layout 是否包含所有的 Maven 依赖，或者在 pom.xml 里执行mvn clean package看是否报错。

第二类：Connection refused或Access denied for user 'root'@'localhost'。前一个是 MySQL 服务没启动，后一个是数据库密码不对或账号权限不足。这里有个排查技巧：先在 Navicat 或命令行里用同样的账号密码连接一次 MySQL，确认数据库层是通的，再回来看应用配置。不要在代码层面上瞎猜。

第三类：JSP 编译错误显示Unable to compile class for JSP。这个通常是 JDK 版本和 Tomcat 的 JSP 编译器不兼容，或者项目使用的 Java 版本高于 Tomcat 支持版本。换成 JDK 8 + Tomcat 8.5 是这类问题的最优解——这两个版本是老 Java Web 项目经过最多验证的搭配，网上能找到的报错案例也几乎都是基于这个组合。

提示：启动成功后不要急着进页面，先在浏览器访问http://localhost:8080/项目名/login.jsp，如果看到登录页静态资源（CSS/JS）全部错乱，大概率是项目路径配置问题——检查 basePath 是否写死成了/项目名/。

4. 核心业务代码拆解：采购入库到库存变动的完整链路

4.1 Service 层事务边界：为什么一张采购单要配一个事务

供应链系统里最不能出错的业务是采购入库——它涉及多张表的联动更新：采购单状态要从「待入库」变成「已入库」，库存表要增加数量，库存流水表要插一条入库记录，如果入库时还涉及应付账款，应付表也要更新。这四个操作不能「成功三个失败一个」，否则库存账面和实际就对不上，这就是事务的用武之地。

课程设计里的 Service 方法，我一般会给它加@Transactional注解，并明确事务回滚条件。Spring 默认只在遇到RuntimeException时回滚，受检异常（如Exception）不会自动回滚，这是一个经典的面试坑，也是答辩时老师可能追问的细节。稳妥的做法是指定rollbackFor：

@Transactional(rollbackFor = Exception.class) public void confirmPurchaseOrder(Integer orderId) { // 1. 校验采购单状态必须是待入库 PurchaseOrder order = purchaseOrderMapper.selectById(orderId); if (order == null || !"待入库".equals(order.getStatus())) { throw new BusinessException("采购单不存在或状态不允许入库操作"); } // 2. 更新采购单状态 order.setStatus("已入库"); purchaseOrderMapper.updateById(order); // 3. 遍历订单明细，逐条增加库存并写入流水 List<PurchaseOrderItem> items = purchaseOrderItemMapper.selectByOrderId(orderId); for (PurchaseOrderItem item : items) { stockMapper.increaseStock(item.getProductId(), item.getQuantity()); StockLog log = new StockLog(); log.setProductId(item.getProductId()); log.setChangeType("采购入库"); log.setChangeQuantity(item.getQuantity()); log.setOrderNo(order.getOrderNo()); stockLogMapper.insert(log); } }

这段代码的逻辑很简单，但有三个细节值得在答辩时展开：一是第 5 行的状态校验，防止重复入库——如果不校验，用户在页面上连续点两次「确认入库」，库存就翻倍了；二是第 13 行的increaseStock在 Mapper 里应该写UPDATE t_stock SET quantity = quantity + #{qty} WHERE product_id = #{productId}，而不是先SELECT再UPDATE——后者在高并发下会丢更新；三是第 18 行的库存流水，这是追溯的凭证，没有它库存数据就是黑匣子，出了问题只能拍脑袋。

4.2 手动事务场景：一个 Service 里调用多个 Mapper 的注意事项

注解事务虽然好用，但有个前提：方法必须是 public 的，而且是 Spring 代理对象调用的。同一个类内部this调用带有@Transactional的方法，事务会失效——这是 SSM 项目里极其隐蔽的一个坑，报错不会出现，但数据就是不回滚。我见过有同学在 Service 里写了两个方法，A 调用 B，B 上标了事务，A 没标，结果 B 里的插入操作失败后，前面的更新操作没有回滚，库存和流水对不上，查了半天才发现是代理失效。

如果确实需要在同一个类里完成多步骤数据库操作，有两个方案：一是把事务操作拆到独立的 Service 类里，通过注入的方式调用；二是用TransactionTemplate编程式事务，手动指定事务边界：

public void confirmPurchaseOrderWithManualTx(Integer orderId) { transactionTemplate.execute(status -> { try { // 更新采购单状态 purchaseOrderMapper.updateStatus(orderId, "已入库"); // 增加库存 List<PurchaseOrderItem> items = purchaseOrderItemMapper.selectByOrderId(orderId); for (PurchaseOrderItem item : items) { stockMapper.increaseStock(item.getProductId(), item.getQuantity()); } return null; } catch (Exception e) { status.setRollbackOnly(); throw e; } }); }

编程式事务的优点是边界极其清晰——你清楚的知道事务从哪一行开始、到哪一行结束，不会被 Spring AOP 的代理机制干扰。缺点是不如注解声明式优雅，代码里会有 try-catch 和setRollbackOnly的样板代码。课程设计项目里，用注解事务就够，但你要能在答辩时说出「我知道事务失效的场景，所以我这样规避」，这句话能挡住一半的追问。

4.3 Controller 层不要写业务：MVC 各层的职责红线

供应链系统的 Controller 层代码，课程设计里常见的错误是又长又乱——校验、组装、调 Mapper、写日志全堆在一个方法里。几百行的一个savePurchaseOrder(HttpServletRequest request)，看着能跑，但答辩时一旦被问「这个方法的职责是什么」，就露馅了。MVC 各层的职责划分，我在做项目时有一条红线：Controller 只做参数接收、调用 Service、返回结果；Service 只做业务逻辑和事务；Mapper 只做 SQL 操作。

我给这套系统设计 Controller 时，会定义一个统一返回值Result对象，所有接口都返回这个结构，前端拿到后判断code字段决定是否弹出成功提示。这样做的好处是：不管前端用的是 jQuery 发 AJAX 还是有页面跳转，后端接口都不需要跟着前端形式改来改去。一个典型的 Controller 方法长这样：

@Controller @RequestMapping("/purchase") public class PurchaseOrderController { @Autowired private PurchaseOrderService purchaseOrderService; @PostMapping("/confirm") @ResponseBody public Result confirm(@RequestParam("orderId") Integer orderId) { try { purchaseOrderService.confirmPurchaseOrder(orderId); return Result.success("入库成功"); } catch (BusinessException e) { return Result.error(e.getMessage()); } catch (Exception e) { logger.error("确认采购单异常", e); return Result.error("系统异常，请联系管理员"); } } }

这段代码的逻辑：第 8 行接收前端传来的订单 ID，第 10 行调用 Service，第 12 行捕获业务异常并返回给前端具体的失败原因，第 14 行捕获未知异常。这里有一个细节：不要把原始异常直接返回给前端——比如数据库约束冲突的英文报错，用户根本看不懂，也会暴露 SQL 结构。用一个通用的「系统异常」文案兜底，把详细错误写进日志，这是企业项目的做法，也是答辩时能加分的小细节。

5. 供应链系统避坑：从数据库到部署的 8 条踩坑记录

5.1 数据库备份跨版本恢复：sql server 2012 备份无法在 2008 上还原

这条看着像是 SQL Server 的问题，但放到供应链管理系统上场景非常真实——很多课程设计的数据库备份文件是用高版本数据库导出、发给同学或老师用低版本还原的。SQL Server 的备份文件是向下不兼容的：2012 生成的.bak文件不能在 2008 上直接还原，报错往往是「数据库备份文件的版本不兼容」。这不是你操作的问题，是版本间的硬限制。

替代方案有三种：一是在高版本数据库上把库结构脚本和 INSERT 语句分别导出，生成纯 SQL 文件，低版本执行这些脚本重建表和数据；二是使用数据库的导入导出向导，把表数据导出为 INSERT 语句；三是直接用第三方的数据比较工具同步表结构。哪种最省事取决于表数量——供应链系统的表一般十张左右，直接导出 SQL 脚本重放一遍是最快的，但要注意自增列的处理，否则外键对应的 ID 会错乱。

5.2 MySQL 显示正在装载：连接数耗尽还是服务启动未完成

Navicat 或命令行连 MySQL 时提示「正在装载」或ERROR 1040: Too many connections，在课程设计项目里也遇到过。原因通常是：代码里的数据库连接没有正确关闭，每个请求都占用一个连接不放，连接数被耗尽。早期的 JSP 项目里DriverManager.getConnection()之后不close()，是这类问题最常见的根源。另一个场景是 MySQL 服务刚启动时还在初始化，此时连接会被挂起，本地表现为永远「正在装载」。

解决方式：先检查代码里是否有连接泄漏——看 DAO 或 Mapper 里的连接获取方式，如果用的是 JDBC 裸写，finally块里必须有conn.close()；如果用的是 MyBatis，依赖连接池会自动归还连接，但也存在事务没提交或回滚导致的连接占用。用完一个SELECT * FROM information_schema.processlist;看当前连接数，如果全是Sleep状态且数量巨大，就是连接泄漏实锤。

5.3 JSP 页面中文乱码：一处设置漏了，全局白搭

乱码问题在供应链系统里几乎人人都会碰到，而且坑在于：明明数据库里是中文正常，查询出来的页面却是???或者乱码。根源是字符集在四个环节里必须一致：数据库表字符集、JDBC 连接字符串、JSP 页面编码、HTTP 响应编码。任何一个环节用了默认的 ISO-8859-1，中文必乱。

排查顺序我一般是：先看 JSP 页面头部有没有pageEncoding="UTF-8"；再看 web.xml 里有没有配置CharacterEncodingFilter；最后看 JDBC 连接字符串是否带了characterEncoding=utf8。前两个对，问题就在连接字符串。前端页面显示的乱码如果长这样系统，是 UTF-8 被当成 ISO-8859-1 解码的典型产物，修改 JSP 的contentType并加上response.setContentType("text/html;charset=UTF-8")能解决。

5.4 库存负数问题：前端校验拦不住并发

供应链系统里做销售出库时，如果库存只有 3 件，但用户同时下了两个 2 件的单，系统可能两张单都成功——因为两个请求同时读到库存还有 3，都判断「够减」，各自减 2，最后库存变成 -1。这是典型的并发扣减库存场景。课程设计里用单线程测试不会暴露，但答辩老师一句话就能问倒：「如果两个人同时买最后一件商品怎么办？」

生产级做法是乐观锁：库存表里加一列version，更新时UPDATE t_stock SET quantity = quantity - #{buyQty}, version = version + 1 WHERE product_id = #{productId} AND quantity >= #{buyQty}。受影响行数为 0 就说明库存不足或版本不对，商品就卖超不了。这个写法在高并发下也能保证库存不会变成负数——因为无论多少个请求同时执行，数据库行锁会让它们串行化，后执行的会因quantity >= #{buyQty}不满足而失败。

5.5 采购入库重复点击：幂等性设计缺失

用户采购入库时，前端提交请求后如果网络慢，用户习惯性再点一次「确认」，系统就会执行两次入库操作。Service 层如果不做校验，采购单状态已经被改成「已入库」，第二次再改状态是成功但无效果的，但问题是明细表里会插两条入库流水，库存会加两次。时间一长，库存账和实物就对不上，这个 bug 的隐蔽性在于——它只在特定操作节奏下出现，测试时很难复现。

我的做法是在 Service 方法开头先做状态机校验，采购单状态不是「待入库」就抛异常。同时在前端按钮上做防重复提交，提交后按钮置灰。两个维度同时做，比单靠一端的保险可靠得多。这类问题答辩时被问到的概率很大，答不好会暴露你根本没考虑过实际业务流程中的异常情况。

5.6 项目里报了 SQL 语法错误但是表存在：索引或保留字踩坑

有一类报错极其折磨人：SQLSyntaxErrorException或Unknown column，但你去数据库里执行同样的 SQL 却没问题。排查后往往发现是表的字段名撞了 MySQL 的保留字。比如有的表把描述字段命名为description、type、level，这些在 MySQL 里虽然不是严格保留字，但在某些版本里会被特殊解析，SQL 拼接时如果不加反引号就可能报错。

解决方式是：建表时避开保留字，字段名统一加业务前缀——比如product_name而不是name，order_status而不是status。这不仅是避坑，也是提升可读性的好习惯。如果已经建好了表不想改字段名，就在 SQL 里给字段名加反引号包裹，MyBatis 的 XML 里写`type`，能解决，但不如从源头改名干净。

5.7 重启 Tomcat 后修改的数据消失：内存型存储的危害

有些课程设计为了简单，会把部分数据放内存 Map 或 List 里，不落库。表现是：页面上增删改查都正常，重启 Tomcat 后数据全没了。这在供应链系统里是大忌——库存和订单数据放在内存里，等于没有任何持久化保障，业务流程一跑就露馅。如果源码里有这类实现，建议尽快改成数据库读写，不要抱有侥幸心理。

这类问题在答辩里也很致命：老师现场登录、添加一条商品数据、重启项目、刷新页面，发现数据没了。这就是没有持久化的最直接证明。如果你的课程设计时间足够，哪怕只是把核心的供应商、商品、库存表走数据库读写，也比全内存实现强一个等级。改的时候要同步改 Service 和 Mapper，工作量可控。

5.8 前端页面 404 或样式丢失：项目路径和静态资源映射

系统部署到一个新环境下，最常见的 404 是页面路径不对，而不是代码有问题。JSP 项目里，页面的相对路径如果写成了/css/style.css，在http://localhost:8080/supply_chain/下访问时，浏览器会去http://localhost:8080/css/style.css找，而不是项目的静态资源目录，自然 404。解决方式是使用${pageContext.request.contextPath}作为所有静态资源链接的前缀，或者在 JSP 顶部定义一个basePath全局变量。

如果你用的是 SSM 框架且配置了<mvc:resources>映射，注意这个配置不能拦截 JSP 的访问路径。SpringMVC 的DispatcherServlet如果设置了/作为映射路径，静态资源（CSS、JS、图片）会全部被拦截，必须显式放行：

<!-- 放行静态资源，否则 CSS/JS 全部被 DispatcherServlet 拦截 --> <mvc:resources mapping="/static/**" location="/static/" />

这里的/static/**是 URL 模式，/static/是物理目录。如果你项目里静态资源和页面在同级目录，就需要根据实际目录结构调整。好在课程设计的源码里通常已经配好了，你需要做的只是确认这段配置没有被改动过。

6. 最后一公里：把系统改成「你自己的」并做出答辩亮点

拿到现成源码后，最怕的就是一个字不动直接交——老师见过几百份相同的课程设计，一眼就能看出来源码是下载的。改造成你自己的项目，不需要推翻重写，只需要做三件低成本高回报的事：改数据库表名和字段名的语义、加一个源码里没有的小功能、在答辩演示时讲清楚一个技术亮点的完整链路。

我建议加的功能是「库存预警列表」——很多课程设计的供应链系统虽然有warning_stock字段，但没有真正把低于阈值的商品挑出来展示。你可以写一个查询：SELECT * FROM t_stock WHERE quantity <= warning_stock，把结果在首页用红色表格列出来。这个功能只需要一个 Mapper 方法、一个 Service 方法、一个 Controller 接口、一个 JSP 页面，工作量半天，但演示效果非常直观——你可以在答辩现场把某商品库存改到阈值以下，刷新页面，红色预警出现，这一套动作比背十页 PPT 都有效。

另一个建议是验证数据一致性：把你新加的采购入库流程完整走一遍——建供应商、建采购单、审核、确认入库、查看库存和流水、再做一次出库，最后去数据库里SELECT这几张表，确认每个环节的数量都对得上。如果中途发现库存不对或者流水缺失，说明事务或幂等校验有问题，这正是需要提前修的——不要在答辩当天让老师看到库存对不上。

我在这个方向上的习惯是：每次改完代码，先把 MySQL 服务停掉重启一遍，再重启应用，全流程重新走一次。因为环境冷启动比热部署更容易暴露资源没释放、缓存失效、初始化顺序错乱等问题。冷启动能过、热部署也能过的项目，才敢拿去演示。希望这篇笔记帮你在把系统跑起来、改到位、讲清楚这条路上少走几步弯路。

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