基于SSM和Vue的抗疫物资管理系统毕设完整指南

“毕设题目到底选什么”这事，每年都能逼疯一批人。选个纯管理系统，怕太简单过不了；选个算法项目，又担心写不完代码。如果你现在手里拿到的题目是“基于SSM和Vue的抗疫物资管理系统”，我倒是觉得这是个挺稳的选择——技术栈经典、业务逻辑清晰、工作量饱满，论文也好展开。这篇东西不打算跟你客气什么，直接从系统设计、数据库、后端、前端、论文写作到答辩常见坑，一条龙拆给你看，读完你就能照着搭。

1. 选题价值与整体方案设计

1.1 这类题目为什么经久不衰

先说个实在话。每年毕业设计里，管理信息系统永远是主流，不是因为学生没创意，而是因为这类题目在“工作量展示”和“技术深度”之间最容易找到平衡点。一个物资管理系统，表面看是增删改查，但实际做下来，你会碰到库存计算、状态的流转、审批流程、报表统计、权限控制这些非常具体的问题，每一块都能写进论文里当独立章节。

抗疫物资管理系统还有一个天然优势：业务场景足够明确。物资分类、入库、出库、申领、审批、库存预警、统计大屏，这些功能模块一听就懂，需求分析不用凭空想象，答辩时老师问你“这个功能为什么这么设计”，你也能给出业务上的解释，而不是只能说“为了完成功能而功能”。

再说技术选型。SSM（Spring + SpringMVC + MyBatis）加上 Vue 的前后端分离方案，在目前的毕设生态里属于“万能公式”级别的组合。这套组合能跑通完整的请求链路：Vue 页面发送异步请求，SpringMVC 接收并路由，Spring 管理业务对象和事务，MyBatis 负责数据库读写。整个过程有清晰的层次划分，论文里画架构图、时序图都有现成素材。而且这套技术在企业里仍然有大量存量项目在用，写进简历也不算丢人。

1.2 功能模块怎么拆最合理

我在帮人看毕设代码的时候，发现一个通病：功能模块列了一大堆，实际上很多是凑数的。比如“系统管理”里硬拆出“菜单管理”“角色管理”“用户管理”“日志管理”，每个模块就一张表、两个页面，看着很多，实际上核心业务根本没有深入。

对于抗疫物资管理系统，我建议把功能模块收敛成四个核心域，再加一个系统管理兜底：

• 基础信息域：物资类别、物资信息、供应商信息、仓库信息。
• 库存业务域：入库登记、出库登记、库存查询、库存预警。
• 申领审批域：申领单创建、逐级审批、审批结果回写。
• 数据统计域：入库统计、出库统计、库存分布、月度趋势。
• 系统管理域：用户管理、角色权限、日志记录。

这个拆分逻辑是顺着业务走的。先有“物资是什么、放在哪”，才有“入和出”，然后才有“别人来申领、我来审批”，最后所有数据沉淀成统计报表。答辩时老师问“你的系统核心流程是什么”，你顺着这条链讲，逻辑是通的。如果上来就讲用户管理、菜单管理，等于把最重要的亮点藏在了最后。

我特别想提一句：申领审批这个环节别省掉。很多同学做的“物资管理系统”就是简单的进销存，申领就是填个出库单，库存减一下。加上审批流之后，系统复杂度立刻上来了——谁来审批、审批不通过库存怎么处理、同一批物资多人并发申领怎么防止超发。这些东西一旦做出来，论文里“系统设计难点”这一节就有东西写了。

1.3 前后端分离架构的落地方式

既然用了 SSM 和 Vue，我就默认你走的是前后端分离的路线，而不是在 JSP 里嵌 Vue。分离的好处是前端项目可以独立启动、独立调试，后端只需要提供 JSON 接口，联调时用 Swagger 或者直接 Postman 测接口都方便。

后端的工程结构建议这样分：

src/main/java ├── com.example.ems │ ├── controller // 接口层，只做参数接收和结果封装 │ ├── service // 业务逻辑层，处理事务和业务规则 │ ├── mapper // MyBatis 数据访问接口 │ ├── entity // 数据库实体类 │ ├── common // 公共类：统一返回结果、异常处理、工具类 │ └── config // 配置类：CORS、拦截器、Swagger等

前端 Vue 工程建议用 Vue CLI 或者 Vite 搭，目录结构按 view 和 api 拆：

src ├── api // 每个模块的接口请求封装 ├── assets // 静态资源 ├── components // 通用组件 ├── router // 路由配置 ├── store // 全局状态（简单项目 Pinia 或 Vuex 都行） └── views // 页面组件 │ ├── dashboard // 统计大屏 │ ├── stock // 库存管理 │ ├── inbound // 入库管理 │ ├── outbound // 出库管理 │ ├── apply // 申领审批 │ └── system // 系统管理

前后端通信统一走 JSON，后端接口返回值封装成统一格式。这里我踩过坑，最开始图省事让后端直接返回各种乱七八糟的 Map，前端取数据要跟后端同学对字段名，改一个字段两边都要动。后来统一了返回到前端的数据结构，所有接口只返回一类对象，前端 axios 响应拦截器里统一处理业务状态码，清爽多了。这个细节也建议你写进论文里，属于“接口规范设计”的一部分。

2. 数据库设计与库存计算的核心思路

2.1 核心表结构如何设计

数据库是整个系统的地基。ARAS（管理员）和普通用户先不管，先琢磨业务表。我把核心表列出来，你可以直接照着建：

物资类别表（material_category）

物资信息表（material）

入库记录表（inbound_record）

出库记录表（outbound_record）字段类似入库表，但要加一个 apply_id 关联申领单。这个字段很重要，它把出库和申领审批串起来，避免出现“审批通过了但没出库记录”或者“没审批就出库”这种数据不一致的情况。

申领单表（apply_order）

申领明细表（apply_detail）

很多人设计申领单时，喜欢把多个物资直接塞到一个字段里，用逗号分隔。这是大忌。一旦需要统计“某种物资被申领了多少”、或者“某条申领明细对应哪条出库记录”，这种设计就废了，只能靠字符串切割，效率低还容易出错。申领主表加明细表，是一对多的标准设计，必须拆开。

2.2 库存数量到底怎么算

库存数量的计算方式，我建议不要在数据库里单独存一个 stock 字段。为什么？因为一旦出现数据修正、误操作回滚，单独存的字段很容易和出入库流水对不上。正确的做法是：库存 = 累计入库 - 累计出库，通过 SQL 实时聚合，或者用一个专门的库存表记录汇总值，但每次出入库时在同一个事务里更新。

用 SQL 实时聚合的表设计，我会建一张库存表（stock）用来做冗余，但它的值只在入库和出库事务里被更新，而不是直接当成唯一数据源。查询时优先读库存表，同时提供一个“重算库存”的接口，管理员可以手动触发重新聚合，修复可能出现的误差。

入库时更新库存的逻辑，放在 Service 层，用事务注解控制：

@Override @Transactional(rollbackFor = Exception.class) public void inbound(InboundDTO dto) { // 1. 插入入库记录 InboundRecord record = new InboundRecord(); record.setMaterialId(dto.getMaterialId()); record.setQuantity(dto.getQuantity()); record.setInboundTime(new Date()); inboundRecordMapper.insert(record); // 2. 更新库存表的可用库存 Stock stock = stockMapper.findByMaterialId(dto.getMaterialId()); if (stock == null) { stock = new Stock(); stock.setMaterialId(dto.getMaterialId()); stock.setAvailableStock(dto.getQuantity()); stockMapper.insert(stock); } else { stockMapper.increaseStock(dto.getMaterialId(), dto.getQuantity()); } }

出库的逻辑类似，但要对可用库存做校验，防止扣成负数。这里我建议在数据库层面也做一道约束，比如出库前先查一次库存，不够就抛业务异常；同时也可以用乐观锁（版本号字段）防止并发情况下两个人同时申领最后一份物资，导致超发。乐观锁的写法很简单：

UPDATE stock SET available_stock = available_stock - #{quantity}, version = version + 1 WHERE material_id = #{materialId} AND available_stock >= #{quantity}

受影响行数为 0，说明库存不足或者版本冲突，直接返回失败。这个做法在实际开发里非常常见，写进论文里能让“并发控制”这个小节有血有肉。

2.3 库存预警怎么实现

库存预警不用搞复杂的定时任务。最简单的方案是：每次查询库存列表时，在 SQL 里比较 available_stock 和 safety_stock，小于等于安全库存就返回一个 lowStock 标记；前端看到这个标记，在表格行显示“库存不足”标签。

如果想让预警更“高级”一点，可以加一个定时任务，每天固定时间扫描库存表，发现有物资低于安全库存，就生成一条预警记录，推送给管理员。定时任务在 SSM 项目里用 Spring 的 @Scheduled 注解就能实现：

@Component public class StockWarnTask { @Autowired private StockService stockService; @Scheduled(cron = "0 0 8 * * ?") public void dailyStockCheck() { List<StockWarnDTO> warnList = stockService.findLowStockList(); for (StockWarnDTO warn : warnList) { // 生成预警记录，写入 warn_record 表 stockService.createWarnRecord(warn); } } }

这个定时任务的 cron 表达式可以按需改。我做这个功能的时候，把扫描频率设成了每小时一次，结果开发测试时频繁触发，数据库里攒了一堆测试预警数据。后来改成每天早上八点跑一次，并且给预警记录加了“已处理/未处理”状态，才像回事。这个小坑你在测试时要注意。

3. 后端核心逻辑与接口实现

3.1 SSM 整合时候容易出的幺蛾子

SSM 整合算是个熟练工种，但对第一次做的人来说，坑集中在配置上。我用的是 Spring + SpringMVC + MyBatis 的组合，配置上主要有三块：web.xml（或者 Java Config）、Spring 配置文件、MyBatis 配置文件。

最常出错的地方是 Spring 和 MyBatis 的扫描路径对不上。Spring 要管理 Service 和 Mapper 接口，Mapper 接口要用 @MapperScan 注解扫描，如果包名写错，启动时直接报“找不到 Bean”的错误。另外，SpringMVC 的配置文件只扫 Controller，不要把 Service 注解也扫进去，否则会出现事务失效的问题。这个现象很隐蔽，代码编译正常、运行也正常，但一旦某个方法抛出异常，数据不会回滚，因为 Spring 容器里存在两个 Service 实例，事务管理器管不到 Controller 用的那个。

检查事务是否生效，有个简单办法：在一个 Service 方法里故意抛 RuntimeException，看数据库里已经执行的前半段 SQL 是否回滚。不回滚就说明事务配置有问题，多半是扫描路径重复或者没加 @EnableTransactionManagement。这个测试方法建议你开发阶段就试一下，别等到答辩前才发现数据错乱。

Mapper 的写法上，我推荐 XML 方式，不推荐纯注解。注解适合简单 SQL，但一旦涉及动态 SQL（比如多条件组合查询库存、按时间区间统计出入库），XML 里的 、 标签才是正解。举个库存多条件查询的片段：

<select id="findStockByCondition" resultType="com.example.ems.entity.Stock"> SELECT s.*, m.name AS material_name, m.spec, m.unit FROM stock s LEFT JOIN material m ON s.material_id = m.id <where> <if test="materialName != null and materialName != ''"> AND m.name LIKE CONCAT('%', #{materialName}, '%') </if> <if test="categoryId != null"> AND m.category_id = #{categoryId} </if> <if test="lowStockOnly != null and lowStockOnly == true"> AND s.available_stock &lt;= m.safety_stock </if> </where> ORDER BY s.update_time DESC </select>

这段 SQL 里的 标签会自动去掉第一个多余的 AND，比在 Java 代码里手动拼接 WHERE 条件舒服得多，也不容易漏空格。

3.2 关键接口的设计逻辑

后端接口设计别搞得太随意，要有一套自己的规范。我统一用 RESTful 风格，资源用名词复数，动作交给 HTTP 方法。比如：

• POST /api/inbound-records 新增入库
• POST /api/outbound-records 新增出库
• GET /api/stocks 分页查询库存
• GET /api/stocks/low 查询低库存列表
• POST /api/apply-orders 创建申领单
• PUT /api/apply-orders/{id}/approve 审批通过
• PUT /api/apply-orders/{id}/reject 审批驳回
• GET /api/dashboard/summary 统计看板数据

所有接口返回统一的 Result 结构：

public class Result<T> { private Integer code; // 200成功，500失败 private String message; // 提示信息 private T data; // 业务数据 public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

前端 axios 封装里，统一拦截 code，非 200 直接弹错误提示。这样做的好处是，后端的异常信息能直接透传到页面，比如“库存不足，当前剩余 5 个”，用户一眼能看到为什么操作失败。

3.3 审批流程的状态机设计

申领审批是我认为这个系统里最有含金量的业务逻辑。别小看一个状态字段，它背后涉及操作顺序的约束。我设计了这么几条规则：

• 只有状态为“待审批”的申领单，才能执行审批通过或驳回操作。
• 审批通过时，系统要检查库存，如果库存不足，审批不能通过，要返回“库存不足”的错误。
• 审批通过后，自动生成出库记录，并扣减库存。
• 审批驳回时，不做任何库存操作，但要记录审批意见。

审批通过时，涉及两个动作：“更新申领单状态”和“生成出库记录 + 扣库存”，这两个动作必须在一个事务里。如果分开执行，可能出现申领单显示已通过，但库存没扣减，或者库存扣了但没出库记录的脏数据。

我在代码里是这么做的：

@Override @Transactional(rollbackFor = Exception.class) public void approveApplyOrder(Integer applyId, Integer auditUserId, String comment) { ApplyOrder applyOrder = applyOrderMapper.selectById(applyId); if (applyOrder == null) { throw new BusinessException("申领单不存在"); } if (!"0".equals(applyOrder.getStatus())) { throw new BusinessException("当前状态不允许审批"); } // 检查库存 List<ApplyDetail> details = applyDetailMapper.selectByApplyId(applyId); for (ApplyDetail detail : details) { int available = stockMapper.getAvailableStock(detail.getMaterialId()); if (available < detail.getQuantity()) { throw new BusinessException("物资【" + detail.getMaterialId() + "】库存不足"); } } // 更新申领单状态 applyOrderMapper.updateStatus(applyId, "1", auditUserId, new Date(), comment); // 生成出库记录并扣减库存 for (ApplyDetail detail : details) { OutboundRecord outbound = new OutboundRecord(); outbound.setApplyId(applyId); outbound.setMaterialId(detail.getMaterialId()); outbound.setQuantity(detail.getQuantity()); outbound.setOperatorId(auditUserId); outbound.setOutboundTime(new Date()); outboundRecordMapper.insert(outbound); stockMapper.decreaseStock(detail.getMaterialId(), detail.getQuantity()); } }

注意这里用了随即的 throw new BusinessException 中断事务，配合 @Transactional 的回滚，才能保证数据一致性。这个函数，基本就是你论文里“业务逻辑实现”这一节的核心代码，建议好好理解每一行。

3.4 权限控制怎么做不给自己挖坑

毕设阶段的权限控制，没必要上 Spring Security 全家桶。倒不是说它不好，而是学习成本高、配置繁琐，容易把自己绕进去。我的做法是：用拦截器加注解控制权限。

先定义一个注解 @RequireRole，标注在 Controller 方法上：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String value(); }

然后写一个拦截器，在请求进入 Controller 之前，从 Session 或 Token 里取出当前用户的角色，判断是否有权限访问：

public class PermissionInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (handler instanceof HandlerMethod) { HandlerMethod handlerMethod = (HandlerMethod) handler; RequireRole requireRole = handlerMethod.getMethodAnnotation(RequireRole.class); if (requireRole != null) { User loginUser = (User) request.getSession().getAttribute("loginUser"); if (loginUser == null) { throw new BusinessException("未登录"); } if (!requireRole.value().equals(loginUser.getRole())) { throw new BusinessException("无权限访问"); } } } return true; } }

这样，在需要管理员权限的接口上标注 @RequireRole("ADMIN")，在普通用户允许的接口上不标注。比在代码里到处 if (role.equals("admin")) 要干净得多，也更容易在论文里描述“基于注解的权限控制设计”。

登录状态我建议用最简单的 Session 方案就够了，毕设不用折腾 JWT 和 Redis。当然如果你项目里用了前后端分离，需要处理跨域情况下携带 Cookie 的问题，那就要在 CORS 配置里设置 allowCredentials。否则前端请求带不上 Session，登录接口能通，但访问业务接口就一直是“未登录”。这个坑极其常见，我见过的前后端分离毕设里至少有一半死在这里。

4. 前端 Vue 页面与交互实现

4.1 路由和权限拦截

前端页面规划直接决定你做出来的东西有没有“系统样”。我的建议是后台管理布局加顶栏侧边栏，这一套用 Vue Router 加视图组件就能实现。

路由需要区分哪些页面需要管理员权限。在路由配置里给每个路由加 meta，然后配合全局前置守卫：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.meta.requiresAuth && !token) { next('/login'); return; } const role = localStorage.getItem('role'); if (to.meta.requiresAdmin && role !== 'ADMIN') { next('/403'); return; } next(); });

这种简单的前端拦截只能控制页面跳转，真正的数据安全还是靠后端接口权限。但页面这一层也不能省，否则普通用户能看到“入库管理”这个菜单，点进去全是 403 报错，体验很差，答辩演示也不好看。

4.2 库存看板页面怎么做

库存看板是整个系统的门面，也是答辩时最容易出彩的地方。我建议做一个综合统计页面，顶部放数字卡片：物资总数、库存总量、低库存预警数、本月出库量。下面放两个图表：近一个月的出入库趋势折线图、各分类物资库存分布柱状图。

图表我用 ECharts，Vue 的封装直接用 echarts 的 npm 包，在组件里初始化并销毁。核心代码大概是：

import * as echarts from 'echarts'; export default { name: 'StockTrendChart', props: { trendData: { type: Array, required: true } }, mounted() { this.chart = echarts.init(this.$refs.chartRef); this.renderChart(); }, methods: { renderChart() { const dates = this.trendData.map(item => item.statDate); const inbound = this.trendData.map(item => item.inboundQty); const outbound = this.trendData.map(item => item.outboundQty); this.chart.setOption({ tooltip: { trigger: 'axis' }, legend: { data: ['入库量', '出库量'] }, xAxis: { type: 'category', data: dates }, yAxis: { type: 'value' }, series: [ { name: '入库量', type: 'line', smooth: true, data: inbound }, { name: '出库量', type: 'line', smooth: true, data: outbound } ] }); } }, beforeDestroy() { if (this.chart) { this.chart.dispose(); } } };

注意 beforeDestroy 里要销毁图表实例，防止内存泄漏。别小看这种细节，页面切换多了之后会变得卡顿，很多时候就是图表没销毁造成的。

统计接口的数据要怎么算？我建议按天聚合，SQL 里用 DATE_FORMAT 函数：

SELECT DATE_FORMAT(inbound_time, '%Y-%m-%d') AS stat_date, SUM(quantity) AS total_qty FROM inbound_record WHERE inbound_time >= #{startTime} GROUP BY stat_date ORDER BY stat_date

出库同理。写 Service 的时候，可以把入库和出库查出来，然后在 Java 里按日期合并成一条折线图需要的序列，避免前端再做复杂的循环匹配。

4.3 出入库和申领审批页面的操作细节

入库页面是个表单，物资下拉、数量、供应商下拉、备注。这里有一个交互细节：选完物资后，最好把当前库存显示出来，方便操作员知道这次入库后大概会有多少库存。数据可以从 /api/stocks/{materialId} 查一下，前端拿到值放在表单单行下方，纯展示。这个功能工作量不大，但演示的时候观感很好，老师会觉得你考虑到了操作员的使用体验。

申领审批页面的核心设计点是待审批列表加详情抽屉。列表里显示申领单号、申请人、部门、申请时间、状态；管理员点“审批”，弹出抽屉或者对话框，里面要有申领明细表格，明确列出每种物资的名称、规格、申请数量、当前库存。当前库存这列很重要，因为审批人必须快速判断能不能通过——库房剩 3 个，有人申请 10 个，还批什么批，直接驳回。

前端在处理审批通过时，我建议做成二次确认弹窗，文案写清楚“通过后将生成出库记录并扣减库存”。不要用 window.confirm，又丑又呆；用 UI 组件库的 MessageBox（Element Plus 里有 ElMessageBox.confirm）友好得多。驳回时弹一个输入框，填审批意见，作为必填项，否则不给提交。

4.4 API 封装规范

前端 API 封装也是个能写进论文的细节。每个模块建一个 js 文件，导出一个包含多个方法的对象。比如库存模块的 api 文件：

import request from '@/utils/request'; export function getStockPage(params) { return request({ url: '/api/stocks', method: 'get', params }); } export function getLowStockList() { return request({ url: '/api/stocks/low', method: 'get' }); }

封装的 request 里统一做超时设置、响应拦截，以及 code 非 200 时自动弹错误提示：

import axios from 'axios'; import { ElMessage } from 'element-plus'; const service = axios.create({ baseURL: '/api', timeout: 10000 }); service.interceptors.response.use( (response) => { const res = response.data; if (res.code !== 200) { ElMessage.error(res.message || '请求失败'); return Promise.reject(new Error(res.message)); } return res.data; }, (error) => { ElMessage.error('网络异常，请稍后重试'); return Promise.reject(error); } ); export default service;

这里有个小技巧：接口返回的结果，在拦截器里直接 return res.data，这样页面组件里拿到的就是业务数据本身，而不是整个 Result 包装对象，不用每次都写 .data.data，省了很多重复代码。这也是一个提升开发效率的好习惯。

5. 论文写作思路与答辩准备

5.1 论文结构怎么安排不像是拼凑的

论文是毕设的另一半。很多同学程序写完了，论文一个字没动，最后几天熬通宵。我的建议是边写代码边攒论文素材，哪怕只是把过程中的截图、测试记录、遇到的问题顺手记在文档里，最后写起来也不会那么痛苦。

论文结构可以参考这样安排：

• 第一章 绪论：研究背景与意义、国内外研究现状、主要工作内容。这里别写太长，重点是引出“为什么要做抗疫物资管理系统”，可以描述传统人工登记方式的痛点：数据分散、统计滞后、库存信息不透明。
• 第二章 相关技术介绍：Spring、SpringMVC、MyBatis、Vue、ECharts。每项技术写两页纸就够，别粘贴大段官方文档。
• 第三章 系统分析：可行性分析、需求分析、功能性需求、非功能性需求。用例图在这里用上。
• 第四章 系统设计：总体架构设计、功能模块设计、数据库设计、接口设计。把我在第2节、第3节讲的表结构、事务控制、审批流程状态机都写进去。
• 第五章 系统实现：按功能模块逐个写实现过程，每个模块配 1-2 张核心代码或页面截图，写清楚关键逻辑。
• 第六章 系统测试：测试环境、功能测试用例表、结论。测试用例表非常重要，是工作量证明，建议每个模块写 5-8 条用例。
• 第七章 总结与展望：写你解决了哪些问题，还有什么不足。

5.2 图表在论文里怎么发挥最大价值

论文里图表是硬通货，多放图一定比多贴代码更能让老师直观理解。建议至少准备这几类图：

系统架构图：分层展示前端、后端、数据库。前端是 Vue 的页面层，后端是 Controller、Service、Mapper 三层，底层是 MySQL 数据库。这个图用 Visio 或者 draw.io 画，画完之后要能清晰看出请求从页面到数据库的完整链路。

用例图：参与者有管理员和普通用户，用例包括登录、物资类别管理、物资信息管理、入库登记、出库登记、申领审批、库存查询、预警查看、统计查看这些。画出用例图后，论文的第三章就非常立体。

时序图：重点画“申领审批”的时序图，从用户提交申领，到管理员审批，到系统扣库存，到返回结果。这个图能非常直观地展示事务控制逻辑，也是答辩时最容易讲清楚的图。

数据库 E-R 图：把核心表的关联关系画清楚。物资表关联类别表、库存表与物资表一对一、申领主表与申领明细表一对多、出库记录关联申领单。

流程图：画一个审批流程图，展示状态流转：待审批 → 通过（生成出库单并扣库存）→ 结束；待审批 → 驳回 → 结束。这种流程图一画，审批逻辑一目了然。

5.3 答辩时老师最喜欢问什么问题

答辩问答环节，老师的问题通常在“为什么”上做文章。我把常见的几个问题先给你预演一下：

“你的系统有哪些角色？权限是怎么控制的？”你能马上说出管理员和普通用户两类角色，并解释用拦截器加 @RequireRole 注解的方式实现。

“库存不足时怎么处理的？”你答：审批通过时校验库存，不足则抛出业务异常，事务回滚，页面提示具体缺多少。同时库存表使用了乐观锁，防止并发超发。

“你和普通的进销存系统有什么区别？”你要答：普通的进销存只关注入出库，你的系统多了申领审批闭环——用户提交申领单、管理员审核、审核后自动生成出库扣减库存、驳回则记录原因。整个流程有完整的数据链条。

“为什么选择 SSM 而不是 Spring Boot？”这个问题要准备好说辞。你可以说毕设选题时考虑技术学习成本、框架原理的掌握程度，SSM 能更清晰地看到 Spring、SpringMVC、MyBatis 各自的分工，对理解 Java Web 开发基础有帮助。别说文不对题，也别贬低 Spring Boot，就说是为了学习框架原理。

“你的并发问题是怎么解决的？”把乐观锁讲清楚，比如 update stock set available_stock = available_stock - q where material_id = ? and available_stock > q，受影响行数为 0 就说明库存不够或者被别的事务改了。这个回答非常加分。

5.4 演示环境的准备

答辩是现场演示，环境准备绝对马虎不得。我见过最尴尬的场景：答辩现场网络连不上数据库、前端端口被占用、图表加载不出来。如果条件允许，直接把环境搭在本地，数据库用本机 MySQL，后端启动在 8080，前端启动在 8081，一切本地化。

提前把常用数据造好：造几条库存预警的数据、造几条已审批和待审批的申领单、造一组近一个月出入库的历史数据，这样演示时图表才有内容，预警标签才会亮出来，整个系统看起来是真实运转过的。

另外答辩用的电脑最好是你自己平时开发用的那台，因为环境都是现成的。如果必须换电脑演示，要提前在演示机上完整走一遍启动流程，确认 JDK、Maven、Node、MySQL 版本匹配。还有就是导出项目的时候，把数据库脚本 SQL 一并导出，演示电脑上先执行脚本建库，省得到时候手忙脚乱。

6. 开发与部署过程中常见问题排查实录

6.1 环境与配置类问题排查

SSM 项目的环境问题，十有八九出在版本和路径上。我把自己在实际开发中碰到的高频问题整理成了一张表，给后来人一个速查手册：

每个问题后面都跟着我当时排查的思路。比如时间偏差这个问题，现象是入库时间显示比实际时间慢 8 小时，原因可能是数据库连接串丢了 serverTimezone=Asia/Shanghai，也可能是 Jackson 没配 GMT+8。两个地方都检查一遍，基本能解决。

6.2 业务逻辑里的深层坑

业务逻辑的坑比环境坑更隐蔽。我整理三个比较典型的：

第一个，删除物资分类时，没有检查该分类下是否还有物资。如果分类有物资却被删了，库存查询 LEFT JOIN 出来的类别名会变成 null，前端表格那一列就空着，查问题要查半天。后来我在前端调接口之前就把这个解决掉：在后端删除分类时，先统计该分类下的物资数，大于 0 就拒绝删除并提示“请先移除该分类下的物资或做归档处理”。

第二个，出库记录和申领单状态不一致。最初我设计审批通过时不生成出库记录，而是让管理员在出库管理页面手动新增一条出库单。后来发现这样很容易出现重复出库——审批通过了一次，出库那边又手动录一次，库存被多扣。改成“审批通过时自动生成出库记录，禁止手动重复登记”之后，这个问题就彻底没了。业务上也不用担心多扣，后台只需要保证“一个申领单最多对应一次自动出库”即可。

第三个，统计报表数据对不上。如果你把入库、出库分开查然后前端拼日期，会漏掉某天只有入库没有出库（或反之）的情况，导致折线图缺日期。解决办法是在 Java 层把两个查询结果按日期合并成一个 Map，日期做 key，补齐缺失的日期，数量置 0。别偷懒让前端做，前端拿到数据再处理会产生额外页面逻辑，数据一多还容易乱。

6.3 性能与体验优化建议

毕设阶段不需要极致性能优化，但有些基本毛病得治。比如分页查询不加条件时，默认要查全表，数据量大了接口响应会很慢。建议分页接口强制带上分页参数，用 PageHelper 或手写 LIMIT 都可以。我习惯手写 LIMIT，代码更直观，也方便在论文里展示：

SELECT s.*, m.name AS material_name, m.spec FROM stock s LEFT JOIN material m ON s.material_id = m.id WHERE 1 = 1 ORDER BY s.update_time DESC LIMIT #{offset}, #{pageSize}

前端列表页默认就请求第 1 页、每页 10 条，用户要翻页才发新请求。这种设计对数据库压力很小。

另外前端上传和导入功能，如果做的话建议限制文件大小。我见过有人上传 100MB 的 Excel，后端直接内存溢出。别在毕设里做花哨的导入导出，如果有这个需求，做导出就行，用 Apache POI 把查询结果写入 Excel，导出接口做个简单处理就够用了。

再就是页面加载态和空数据态。表格加载时显示 loading，查询结果为空时显示“暂无数据”，这些虽然是小细节，但答辩演示时如果接口慢了一两秒，页面什么都没有，观感极差；有 loading 转圈就不一样了，老师知道你的系统在操作。Element Plus 组件自带这些能力，花半小时加上，回报率极高。

6.4 测试用例怎么设计才充实

测试章节是论文里最好写，但也最容易被写得敷衍的部分。我建议不要光写“系统运行正常”这种空话，要设计一本正经的测试用例表。表格至少包含：用例编号、测试模块、测试步骤、预期结果、实际结果、是否通过。

举几个例子：

这些用例写进论文里，工作量看着就满了。而且你在写用例的过程中，等于自己做了一遍系统测试，能提前发现不少 bug，一举两得。

我自己的习惯是每写完一个模块，立刻测一轮，把 bug 记录在一个文档里，修完再测。等全部模块结束，这个文档天然就是论文测试章节的素材。别拖到全部开发完再统一测，那时候代码量大了，定位问题非常痛苦。

7. 从开发到交付的实用提醒

最后分享几个我在实操中特别想提醒的细节。第一，项目文件一定要做版本管理，哪怕只是本地 Git 仓库，每次改动先 commit 一下，防止写到一半代码坏了没有回退点。Git 的使用本身就值得写进简历，也算额外收获。

第二，数据库脚本要随时能重建。把所有建库建表的数据脚本放在一个 sql 文件夹里，每次改了表结构就同步更新。我就是靠这个让项目在不同电脑上都能快速跑起来，答辩换机器也不用慌。

第三，前端端口跨域和登录问题最好提前测通。前后端分离项目的联调，最大的阻碍就是跨域和 Cookie 携带，务必在后端配置里处理好。如果 Redis、JWT 这些新东西学不来，传统 Session 完全够用，别贪多。

第四，答辩前把整个流程完整走三遍以上。从启动后端、启动前端、登录、入库、出库、申领审批、看统计报表，一条龙操作下来，确保自己熟练掌握操作顺序。有些人代码写得好，但演示时找不到按钮在哪，白白扣掉印象分。

做毕设这件事，本质上是给自己一个完整的项目训练机会。代码能力在其次，能不能把事情从头到尾有逻辑地做出来——需求分析、设计、编码、测试、文档——才是真正有价值的收获。这个抗疫物资管理系统，做完你回头看，它不只帮你通过答辩，还会让你对“一个系统是怎么诞生的”有非常具体的体感。这个过程里踩过的每一个坑、解决的每一个 bug，都比最后那个分数值钱得多。