基于SpringBoot3+Vue3的ERP仓储管理系统：毕业设计实现与答辩指南

计算机毕业设计里，管理系统是永远的万金油，但能把“仓储”两个字写出业务深度的并不多。基于SpringBoot3+Vue3的ERP仓储管理系统，正是那种看起来不吓人、做起来有体系、答辩时又能拿得出手的题目。这篇文章我会从选题定位、功能设计、数据库建模、后端核心代码、前端联调、部署演示和答辩准备一路拆到底，把我实际带项目时踩过的坑、认可的做法、以及会直接决定你分数高低的细节全部写出来。无论你是刚拿到任务书的应届生，还是想快速搭一套可演示系统的开发者，都可以照着做，甚至可以直接抄部分代码。

1. 为什么选ERP仓储管理系统作为毕业设计

1.1 “仓储管理”比想象中更适合当毕设

现在网上喊得最多的就是“XX管理系统”，图书管理、学生管理、车辆管理，清一色的单表增删改查。这类题最大的问题是业务太浅，评委一眼能看穿：你的创新点在哪里？你如何体现工程能力？而ERP仓储管理系统天然避开了这个问题，因为它至少要处理两类核心数据：一类是商品、仓库、供应商、客户这些“主数据”，另一类是采购、入库、出库、调拨、盘点这些“业务单据”。更关键的是，库存数量是由业务单据驱动变化的，每次变动都必须留下可追溯的流水记录。这个“业务流驱动数据流”的闭环，恰好是评判一个系统是否真实可用的分水岭。

我实际辅导过一个同学的例子：他起初想做简单的商品管理，后来换成了仓储系统，最终把入库审核、库存预警、盘点盈亏都做完了，答辩时评委连续问了三个业务场景问题，他都能顺着“单据—库存—流水”这条线答出来。成绩比同组做图书管理系统的同学高了不少。原因很简单：题目自带业务深度，不需要你临场编亮点。

1.2 SpringBoot3 + Vue3 这套组合好在哪

先说后端。SpringBoot3要求JDK17起步，默认内嵌Tomcat，配置简化到几乎零XML。相比经典的SSM框架，SpringBoot3+RESTful接口+统一异常处理的开发效率高非常多。最重要的是，SpringBoot3现在是各大企业招聘需求里出现频率最高的后端框架，毕业设计用它，等于直接告诉大家你上手的是主流技术栈。

前端选择Vue3同理。Vue3的组合式API让逻辑复用更清晰，配合Vite开发时的热更新速度比Webpack快一个量级。再加上Element Plus组件库，你能在很短时间做出一套看起来相当专业的后台管理界面。有人会问：为什么不是React？我只能说，在毕业设计这种讲究快速落地、资料好找、社区问题有现成答案的场景下，Vue3的国产生态优势太明显了。而且“SpringBoot3+Vue3”本身就是当前前后端分离项目的标准搭配，写进简历里也站得住脚。

需要注意的是，这套组合有硬性门槛：JDK必须是17以上，MyBatis相关依赖必须使用适配SpringBoot3的版本。很多人卡在启动报错，百分之八十是依赖版本问题，后面我会专门列出排错清单。

1.3 毕业设计要解决的三个核心问题

做毕业设计最怕三件事：功能做不完、逻辑讲不清、答辩被问倒。围绕这三点，我会给出一条完整路线：功能上只做主线闭环，不做大而全；逻辑上用“基础数据—业务单据—库存流水—报表”这条主线贯穿；答辩上准备常见追问和话术。后面所有章节都会围绕这个思路展开，你能直接照搬。

2. 功能规划与数据库建模：先把地基打好

2.1 模块划分：主流程加辅助体系

仓储系统的功能模块可以分成四层，我的划分思路是“对象—动作—记录—边界”：

• 基础数据层：商品分类、商品信息、仓库、供应商、客户。这些是所有业务发生的前提。
• 业务单据层：采购订单、销售订单、入库单、出库单、调拨单、盘点单。这是用户操作的入口。
• 库存核心层：实时库存、库存流水、库存预警。这是系统价值所在。
• 权限与报表层：用户、角色、菜单权限、工作台统计、出入库趋势报表。

为什么要这样分？因为所有业务单据最终都指向一个动作：让某个仓库里某个商品的库存数量发生变化。商品、仓库不重复，库存就有唯一确定的记录；单据需要经过审核才生效，库存变化就有据可依；每次变化都写流水，历史就能追溯。这是整个系统设计的灵魂，也是和普通增删改查最大的区别。

2.2 核心表设计与关键字段

数据库设计直接决定后期开发能不能顺利推进，我建议的表结构大致如下：

我特别强调几个字段的注意事项：所有业务表都要带create_time、update_time和逻辑删除标志deleted；不要把表名直接叫order，因为order是MySQL保留字，查询时需要加反引号，很麻烦，用bus_outbound_order这类名称最省心。金额字段使用decimal(10,2)，数量字段使用decimal(14,3)，不要用float和double，否则累计运算会产生精度误差。

实时库存表要建联合唯一索引，约束(warehouse_id, product_id)。这个索引有两个作用：一是防止同一仓库同一商品出现多条库存记录；二是让库存更新时可以精确定位到一行数据，配合后面的乐观锁实现并发安全。库存流水表则要有独立的流水号，建议用“业务类型+时间戳+随机数”生成，保证在分布式环境下也不会重复。

2.3 权限模型与业务流程设计

权限采用经典的RBAC模型：用户关联角色，角色关联菜单。菜单分为目录、菜单、按钮三级，按钮权限对应后端的接口权限。前端根据用户角色动态生成路由和侧边栏，后端在核心接口上增加权限校验。最简单的实现是使用Sa-Token框架，它提供了直接可用的注解式鉴权，比Spring Security配置量小很多。

业务流程上，我强烈建议加入“审核”环节。例如采购入库单创建后，库存数量不变，只有审核通过后，库存才真正增加。这样做既符合真实业务习惯，也是答辩时的加分项。同理，销售出库单审核通过后库存才扣减。盘点单则先填账面数量与实际数量，审核后根据差异自动调整库存。整套流程最终落到库存流水表中，任何一笔库存变化都能回答“什么时候变的、为什么变、变了几件”这个问题。

3. 后端实现：SpringBoot3 项目搭建与库存核心代码

3.1 项目初始化和关键依赖

环境要求：JDK17，Maven3.8以上，MySQL8.0。Spring Boot版本选3.2.x或3.3.x都行，我用的是3.2.4。pom.xml里需要重点关注的依赖如下：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.4</version> </parent> <properties> <java.version>17</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-spring-boot3-starter</artifactId> <version>3.5.7</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>cn.dev33</groupId> <artifactId>sa-token-spring-boot3-starter</artifactId> <version>1.37.0</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

注意mybatis-plus必须引入带spring-boot3后缀的starter，否则会出现ClassNotFoundException。application.yml中的核心配置如下：

server: port: 8081 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/erp?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

分页插件必须在配置类中注册，否则分页查询会查出全部数据：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

3.2 库存变更与流水记录：核心逻辑一次写对

库存变更这块是整个系统的命门。最容易犯的错误是先查库存，判断够不够，再执行更新。这种写法在高并发下会超卖，因为两个请求可能同时读到相同的库存数。正确写法是把判断条件放进SQL的update语句里，用受影响行数来判断是否成功。以出库为例：

@Transactional(rollbackFor = Exception.class) public void outStock(Long warehouseId, Long productId, BigDecimal num, String orderNo) { int rows = stockMapper.deduct(warehouseId, productId, num); if (rows == 0) { throw new ServiceException("库存不足或商品不存在"); } // 重新查询最新库存，生成流水 StockWarehouseProduct stock = stockMapper.findByWarehouseAndProduct(warehouseId, productId); StockRecord record = new StockRecord(); record.setBizType("OUT"); record.setOrderNo(orderNo); record.setProductId(productId); record.setWarehouseId(warehouseId); record.setChangeNum(num.negate()); record.setAfterNum(stock.getStock()); stockRecordMapper.insert(record); }

对应的XML更新语句是：

<update id="deduct"> update stock_warehouse_product set stock = stock - #{num}, version = version + 1 where warehouse_id = #{warehouseId} and product_id = #{productId} and stock >= #{num} </update>

这条SQL自带判断条件stock >= #{num}，如果库存不足，受影响行数为0，事务回滚，库存不会被扣成负数。再配合@Transactional保证扣库存和写流水要么同时成功，要么同时失败，这就是最基本的并发安全方案。入库逻辑同理，只是把减库存改成加库存，不需要stock >= num条件，但依然要写流水。

审核单据的接口也要做防重复提交。以入库单审核为例，用状态条件更新：

@Transactional public void auditInbound(Long orderId) { int rows = inboundOrderMapper.updateStatus(orderId, 0, 1); if (rows == 0) { throw new ServiceException("该单据已审核或状态不正确"); } // 遍历明细，调用库存变更 List<InboundOrderItem> items = inboundOrderItemMapper.selectByOrderId(orderId); for (InboundOrderItem item : items) { stockService.inStock(item.getWarehouseId(), item.getProductId(), item.getNum(), inboundOrder.getOrderNo()); } }

updateStatus对应SQL为update bus_inbound_order set status = 1 where id = #{orderId} and status = 0。这样即使前端按钮被双击，第二次更新也已不满足status = 0，直接抛异常，流水不会重复生成。

3.3 统一返回结构与全局异常处理

前后端分离项目一定要设计统一返回格式，否则前端校验逻辑会非常痛苦。我常用的结构是：

@Data public class R<T> { private Integer code; private String message; private T data; public static <T> R<T> success(T data) { R<T> r = new R<>(); r.code = 200; r.message = "success"; r.data = data; return r; } public static <T> R<T> fail(Integer code, String message) { R<T> r = new R<>(); r.code = code; r.message = message; return r; } }

再配合@RestControllerAdvice统一捕获业务异常、参数校验异常和兜底异常，让前端看到的永远只有code、message、data三者，便于axios拦截器统一处理。特别提醒，自定义异常ServiceException只需要一个code和message字段，不要让它继承RuntimeException以外的东西。

3.4 分页查询与模糊搜索

列表页都跑不了分页查询。使用MyBatis-Plus的LambdaQueryWrapper可以简洁地完成条件拼接：

public R<IPage<ProductVO>> page(int pageNum, int pageSize, String keyword, Long categoryId) { Page<Product> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Product> wrapper = Wrappers.lambdaQuery(Product.class) .like(StringUtils.hasText(keyword), Product::getName, keyword) .eq(categoryId != null, Product::getCategoryId, categoryId) .orderByDesc(Product::getCreateTime); IPage<Product> result = productMapper.selectPage(page, wrapper); // 转换成分页VO返回 return R.success(convert(result)); }

这里要注意，前端传过来的keyword需要做空字符串判断，否则会拼出无效的like条件。另外，如果业务需要关联查询分类名称、供应商名称等额外字段，建议直接在VO里接收，不要在前端频繁发多次请求。

4. Vue3 前端实现：从工程搭建到核心交互

4.1 Vite + Vue3 + Element Plus 工程搭建

前端使用Vite创建工程：

npm create vite@latest erp-web -- --template vue cd erp-web npm install npm install vue-router pinia axios element-plus

vite.config.js中配置开发代理，解决前后端联调跨域：

import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' export default defineConfig({ base: './', plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } } })

目录结构建议按下面这个约定组织，这是很多实际后台项目都在用的方式：

• src/api：所有接口请求定义，按模块拆文件
• src/views：页面级组件，按功能模块建子目录
• src/router：路由配置，包含静态路由和动态路由逻辑
• src/store：Pinia状态，主要放用户信息和权限菜单
• src/components：通用组件，例如分页封装、表单弹窗
• src/utils：axios实例、格式化工具

4.2 登录状态、token 和动态路由

登录页调用接口成功后，后端返回token、用户基本信息、角色和菜单权限。前端把token存到localStorage，把用户信息和权限存到Pinia。axios请求拦截器里统一带上token：

service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config })

响应拦截器处理code非200的情况，遇到401时清空状态并跳转登录页。这里有个关键细节：刷新浏览器时Pinia中的权限菜单会丢失，所以必须在路由前置守卫里增加判断，如果当前没有权限信息，先调用接口拉取最新用户权限，动态添加路由后重新进入目标页面：

router.beforeEach(async (to, from, next) => { const userStore = useUserStore() if (!userStore.token) { if (to.path === '/login') return next() return next('/login') } if (userStore.menus.length === 0) { await userStore.fetchUserInfo() const routes = buildRoutes(userStore.menus) routes.forEach(route => router.addRoute('Layout', route)) return next({ ...to, replace: true }) } next() })

这一步如果不处理好，非常容易出现刷新页面后路由变成空白或者404，后面常见问题里我会再强调。

4.3 入库单新增与明细动态表格

入库单页面是典型的主子表结构。新增单据的弹窗表单里，头部选择仓库和供应商，明细区域用动态表格维护商品明细。核心逻辑是用reactive维护rows数组，每次新增一行：

const rows = reactive([]) function addRow() { rows.push({ productId: null, num: 1, price: 0 }) } function removeRow(index) { rows.splice(index, 1) } async function submit() { if (rows.some(r => !r.productId || r.num <= 0)) { ElMessage.error('请完善商品和数量') return } await saveInboundOrder({ warehouseId, supplierId, items: rows }) ElMessage.success('保存成功') }

明细中选择商品后，最好自动带出商品编码、规格、单位等只读信息，数量变化时前端实时计算合计金额，这些体验上的小细节会让系统看起来专业很多。查看详情页面建议用el-descriptions展示主表信息，再用el-table展示明细，整体风格统一。

4.4 报表可视化与ECharts使用

工作台或统计报表是让系统显得有“深度”的核心页面。我一般用ECharts做两个核心图表：一个是近7天出入库数量趋势，一个是当前库存按分类分布的饼图。展示趋势时选择折线图，数据来源于后端按日期聚合的统计接口。展示分类库存时用饼图，按分类汇总库存数量。图表不要直接把所有数据写死，接口返回空数据时要给空占位提示。ECharts的包体积较大，建议按需引入，或者简单一点直接在main.js中引入完整包，毕业设计场景下这点体积差无所谓，关键是稳定。

5. 部署、演示与答辩准备

5.1 打包部署：前端打包进后端是最好用的方案

毕业设计演示最容易出事故的就是环境不一致。我最推荐的做法是：前端构建后直接把dist目录复制到后端项目的src/main/resources/static下，再配置一个简单的资源映射规则，让后端jar包同时提供静态页面和API服务。这样你只需要启动一个Java进程，评委打开一个地址就能看到完整系统。

前端构建：

npm run build

然后把dist内的文件全部复制到后端resources/static目录。后端增加一个配置让Spring MVC支持SPA资源定位，同时在路由层面把非/api请求都转发到index.html：

@Configuration public class SpaConfig implements WebMvcConfigurer { @Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController("/{path:[^\\.]*}").setViewName("forward:/index.html"); } }

最终打包命令：

mvn clean package -DskipTests java -jar target/erp-system-0.0.1-SNAPSHOT.jar

浏览器访问http://localhost:8081即可。如果局域网演示，把后端端口暴露给同一局域网，评委在手机上也能打开页面。

5.2 演示数据与场景编排

系统里一定要有足够真实的演示数据，否则你现场创建商品、录入单据会非常尴尬。我一般准备三种数据：基础数据至少20个商品、3个仓库、5个供应商、5个客户；再准备几条已经审核通过的入库单和出库单，让库存查询和流水页面一打开就有内容；最后准备一条待审核单据和一条库存低于预警阈值的商品，演示时正好触发预警。

演示顺序我强烈推荐按业务闭环来：

• 第一步：登录系统，从工作台看到库存预警和今日出入库统计。
• 第二步：新增一个商品，然后创建采购入库单，审核后切到库存查询，展示库存数量增加，再切到库存流水，展示流动记录。
• 第三步：创建销售出库单，审核后库存扣减，如果该商品低于预警阈值，工作台预警数量同步变化。
• 第四步：进入盘点模块，做一次盘盈或盘亏，展示审核后库存差异调整。

这套顺序下来，评委能很直观地看到系统从数据到单据到库存到预警的完整闭环。记住：不要一上来就点开用户管理、菜单管理这种纯配置页面，看着像在证明你只是做了一个后台管理系统模板。

5.3 答辩常见问题与话术准备

答辩时要能回答这几个高频问题：

• 为什么选SpringBoot3？答：SpringBoot3基于JDK17，是当前主流后端开发框架，内嵌Tomcat、自动配置、生态成熟，能让我把更多精力放在核心业务上。
• 库存超卖怎么解决？答：我用带条件的update语句，将库存充足判断合并到SQL中，配合数据库事务和乐观锁版本号，确保并发情况下不会把库存扣成负数。
• 同一张单重复审核怎么办？答：审核操作使用状态条件更新，只有status=0的单据才能被置为1，第二次更新影响行数为0，直接提示“该单据已审核”。
• 为什么权限不用Spring Security？答：毕业设计更关注业务建模和代码清晰度，Sa-Token体积小、注解直观，能快速实现登录、鉴权和踢人下线，如果后续需要复杂OAuth2流程可以再无缝替换。
• 系统能支撑多大规模？答：课程设计和毕业设计场景下几百个用户同时使用没有问题，如果将来要承接更大并发，可以把库存扣减逻辑迁移到消息队列或Redis Lua脚本中。

回答问题不要着急，先把结论说清楚，再补充实现细节。不会的问题直接承认设计时没有考虑，表示后续可以优化，评委反而觉得态度诚恳。

6. 常见问题与排错实录

6.1 环境与依赖版本不兼容

启动报错“Unsupported class file major version 65”意味着JDK版本不够，SpringBoot3必须JDK17以上。报错“ClassNotFound: com.mysql.cj.jdbc.Driver”说明mysql驱动依赖不对，检查是否引入mysql-connector-j。报错“mybatis-plus无法识别分页插件”通常是因为用了老版本的mybatis-plus starter，必须换为mybatis-plus-spring-boot3-starter。我排查过很多次，这些问题集中在依赖版本，建议直接像我上面那样锁定版本号，不要写不带版本号的依赖然后指望Maven自动选。

6.2 前后端联调与数据异常

开发环境接口请求有时通，有时不通，先看Vite代理是否生效。修改vite.config.js后必须重启dev server，代理不是热更新的。请求路径一定要以/api开头，否则不会走代理。后端接口报404，先看control层是否加了@RequestMapping(“/api”)。前端登录后刷新页面白屏或404，十有八九是动态路由没有在刷新后重新构建，按照4.2节的前置守卫逻辑处理即可。

调试建议用浏览器F12的Network面板，专门看请求URL和响应体。如果响应体是HTML而不是JSON，基本说明请求被静态资源兜底策略接住了，检查路径是否被SPA转发规则误匹配。

6.3 库存与流水数据不一致

这是最容易在答辩时被抓住的问题。我遇到过一个真实案例：某人连续点击审核按钮，前端没有做防重复处理，后端也没有状态判断，结果同一张入库单的明细被插入了两次库存流水，库存数量翻倍。解决办法前端在提交后loading按钮，后端用状态条件更新和业务单号唯一索引双重防守。另一个案例是盘点调整库存时没有记录流水，导致库存变了但流水查不到。记住原则：一切库存变化必须落流水，哪怕是盘点差异也必须生成一条盘点类型的流水。

6.4 低成本扩展开源思路

如果你的时间和精力还有余量，可以考虑在现有基础上增加库存周转率报表，基于stock_record按商品和月份聚合，计算周转天数并做成图表。还可以增加Excel导入导出，用EasyExcel实现商品和单据明细的批量导入，这是很多评委眼中的实用功能。也可以做操作日志切面，用AOP记录用户核心操作，生成近30天的审计日志。这些扩展都不算高成本，但能让系统从“课程设计”提升到“企业级项目”的观感。

最后分享一点实际体会：带过这么多套系统，真正拉开分数差的从来不是代码量，而是你是否能一句话讲清楚“基础数据—业务单据—库存流水—报表”这条业务闭环。把库存核心链路做扎实，把并发安全问题想明白，再配合一套顺畅的演示流程，毕业设计不仅稳过，还有机会被推荐为优秀案例。时间不够时请记住优先级：入库、出库、库存查询、库存流水优先做到最好，用户管理、菜单管理、报表其次，其他模块全部可以简化。祝正在为毕设头秃的你，早点做完，早点安心。