简介面向高校计算机相关专业毕业设计场景这可是一套基于Spring Boot、Vue和MySQL构建的智能无人仓库管理项目完整资料。系统针对信息管理混乱、出错率高、劳动强度大等实际痛点实现了货物出入库、补货申请、库存状态跟踪等业务功能并采用前后端分离架构方便在Idea或Eclipse中直接运行与调试适合正在完成仓储类课题或希望学习主流框架整合的开发者使用。压缩包共包含347个文件大小约30.95MB其中82个Java文件对应后端业务逻辑34个Vue文件构成前端管理界面还有15个JS脚本用于交互处理以及SQL数据库脚本、XML和YML配置文件、自动构建的bat脚本、演示视频和毕业论文文档目录层次清晰便于按模块检索与二次开发。目前已有126人学习或下载该资源。通过下载这份资料读者可以获得完整可运行的源代码、数据库表结构、毕业论文以及操作视频既能直接用于毕业设计答辩也能据此快速掌握Spring Boot与Vue的整合流程和项目部署方式。1. 智能无人仓库管理毕设值得做但别把它做成 CRUD 大礼包仓库门口那本纸质台账、入库靠人肉记忆找空位、出库翻半天不知道先发哪批货——这套系统要解决的就是这三件事。基于 SpringBootVueMySQL 开发的智能无人仓库管理本质是用 Web 技术栈把「入库登记、库位分配、出库核销、库存盘点、超期预警」串成一条无人值守的自动化流程毕设里常见形态是「扫码或输入单号自助存取 管理后台看板」。它适合三类人想用前后端分离项目证明工程能力的本科生、需要给管理系统加点业务深度的求职者、以及想搞懂 SpringBootVue 全家桶从数据库到页面怎么才能跑通的新手。相比纯增删改查的系统它的加分点在于「无人」两个字逼着你做业务流程编排和规则逻辑本文按后端、前端、数据库、联调部署、避坑、答辩验证的顺序把完整落地路径讲清楚。2. SpringBootVueMySQL 的组合为什么合适先想清楚技术与业务的对应关系2.1 三层各管什么不是流行才用是分工刚好先看这套组合在无人仓库场景里的分工MySQL 管货架、货物、出入库记录这些事实数据SpringBoot 管业务规则和流程——谁有权限操作、入库放哪个库位、出库是否合规、库存够不够Vue 管人与系统打交道的界面——仓库看板、出入库操作台、库存查询、权限管理。选 SpringBoot 而不是 SSM核心理由是两个一是配置方式从 XML 变成注解自动配置写毕设代码的时间能省出三分之一对一个人开发来说很关键二是内嵌 Tomcat打 jar 就能跑答辩现场的部署环节不容易翻车。选 Vue 而不是 React则是生态原因Element UI 这类组件库把表格、表单、弹窗全备好了仓库管理这类后台管理界面的开发速度会快很多而且中文资料齐全出了 bug 搜得到类似场景。有一点必须提前想明白所谓「无人」在这个项目里意味着「自助式业务流程」而不是「高度人工智能」。具体落地是三件事无人值守入库扫码或输入编号后由系统自动分配库位、无人值守出库系统按先进先出规则给出应出批次、库存自动预警定时任务扫描超期或低库存数据。业务规则清晰程序逻辑就好写答辩时也能讲得清楚。2.2 把「无人」拆成三条可编码的业务规则无人值守不能是口号必须拆成系统能执行的规则。我的做法是定义三条核心规则全部落到后端服务层再在接口层面做校验兜底。规则一入库货物必须有「库位推荐」——系统按「品类分区优先、同区空位优先」的方式从数据库里筛选货架。新增货物时先查品类分区表找到允许存放的货架集合再按当前存量升序取空位最多的货架返回前端操作员确认或由系统自动确定。规则二出库按「先进先出」核销——同一种货物有多批入库记录时出库单默认锁定额度内最早入库的批次。这个规则必须在事务里做否则并发出库时两个请求可能核销同一批货库存数据直接乱掉。规则三权限与操作留痕——普通操作员只能做入库、出库、查询不能改货架基础数据所有出入库请求必须落记录表提供「谁在什么时间做了什么操作」的审计数据。无人仓库的「无人」本质是靠流程纪律和审计兜底不是靠摄像头和机器人。这三条规则落完后系统才具备「业务深度」出库接口不再是一句简单的 SQL UPDATE而是先查批次、算余量、再扣减、后写流水的一整套流程。这也是毕设答辩时最有话聊的部分。2.3 不要做的部分哪些现有选择其实没必要引入常见做法是把系统做复杂引入 Redis 缓存、RabbitMQ 消息队列、Spring Cloud 微服务。我建议全砍掉理由与技术水平无关与项目边界有关。首先单机部署的仓库管理系统并发量在演示场景下就是个位数MySQL 完全扛得住。Redis 缓存如果只是给库存查询加速反而多一套序列化、缓存穿透的维护成本。其次消息队列是分布式系统解耦用的单人开发的单体项目引入它属于自己造复杂度答辩老师追问「为什么用 MQ」时你很难给出一个真实的业务理由。最后微服务在这个规模下是纯负担拆出三个服务就要处理服务间调用、分布式事务、统一配置这些内容在毕设周期内做不透做不透的模块上了台就是送分题。技术选型的合理边界是让每个引入的技术都有业务理由。SpringBoot 管流程编排、Vue 管交互、MySQL 管持久化、定时任务管预警够了。3. 后端与数据库先设计表结构再写事务与规则3.1 五张主表的设计仓库业务的核心实体与关键字段数据库设计是这种管理系统的地基。我习惯先画业务实体图再落建表语句毕设论文里的数据库设计章节也应与建表语句一一对应方便评委照图索骥。整个无人仓库的核心数据表可以收敛为五张用户表、货架表、货物表、入库记录表、出库记录表。关系如下货架表与货物表是位置对应关系货物表与出入库记录表是主档与流水的关系用户表独立支撑权限控制。下面的建表语句可直接用于初始化-- 用户表支撑登录与角色控制 CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT 登录名, password VARCHAR(100) NOT NULL COMMENT BCrypt加密后的密码, role VARCHAR(20) NOT NULL DEFAULT OPERATOR COMMENT ADMIN/OPERATOR, real_name VARCHAR(50) DEFAULT NULL COMMENT 姓名留作审计字段, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 货架表库位主体状态字段决定是否可分配 CREATE TABLE shelf ( id INT PRIMARY KEY AUTO_INCREMENT, shelf_no VARCHAR(20) NOT NULL UNIQUE COMMENT 货架编号如A-01, category VARCHAR(30) NOT NULL COMMENT 允许存放的品类分区, capacity INT NOT NULL DEFAULT 100 COMMENT 最大容量, current_count INT NOT NULL DEFAULT 0 COMMENT 当前已放数量, status TINYINT NOT NULL DEFAULT 1 COMMENT 1可用 0停用, UNIQUE KEY uk_shelf_category_no (category, shelf_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 货物表库存主档注意批次字段是出库核销的依据 CREATE TABLE goods ( id INT PRIMARY KEY AUTO_INCREMENT, goods_no VARCHAR(30) NOT NULL UNIQUE COMMENT 货物编号, name VARCHAR(100) NOT NULL COMMENT 货物名称, category VARCHAR(30) NOT NULL COMMENT 品类与货架分区对应, batch_no VARCHAR(50) NOT NULL COMMENT 入库批次号先进先出依据, quantity INT NOT NULL DEFAULT 0 COMMENT 当前库存量, shelf_id INT DEFAULT NULL COMMENT 所在货架ID, inbound_time DATETIME NOT NULL COMMENT 入库时间, KEY idx_category_batch (category, batch_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 出入库流水表合并为一张操作记录表简化审计逻辑 CREATE TABLE inventory_log ( id INT PRIMARY KEY AUTO_INCREMENT, type TINYINT NOT NULL COMMENT 1入库 2出库, goods_id INT NOT NULL, quantity INT NOT NULL COMMENT 变动数量, operator_id INT NOT NULL COMMENT 操作人ID, before_quantity INT NOT NULL COMMENT 变动前库存留痕字段, after_quantity INT NOT NULL COMMENT 变动后库存, log_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_goods_time (goods_id, log_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有一个毕设常见误区货物表只存当前库存总量没有批次维度。这会导致先进先出规则无法实现。上面的 goods 表把 batch_no 作为独立字段存放同一货物多次入库时会出现多条记录出库时按入库时间排序逐条扣减即可。库存流水表里同时记录变动前后的值是审计和追溯的关键字段不能省。3.2 入库与出库的服务层实现事务边界决定数据一致性表设计完成后看后端核心代码。入库和出库不是简单的 insert/update必须放进同一个事务方法里保证「加库存、更新货架、写流水」三件事要么全成、要么全败。Service RequiredArgsConstructor public class InventoryService { private final GoodsMapper goodsMapper; private final ShelfMapper shelfMapper; private final InventoryLogMapper logMapper; /** * 入库分配货架 写入货物批次 更新货架占用 写流水 * 事务由 Spring 注解控制异常时回滚全部操作 */ Transactional(rollbackFor Exception.class) public void inbound(InboundRequest req, Long operatorId) { // 1. 找到可用的货架同品类且未停用且未满 ListShelf candidates shelfMapper.findAvailable(req.getCategory()); if (candidates.isEmpty()) { throw new BusinessException(该品类暂无可用货架); } // 2. 推荐空位最多的货架当前占用数最少优先 Shelf target candidates.stream() .min(Comparator.comparingInt(Shelf::getCurrentCount)) .orElseThrow(() - new BusinessException(货架分配失败)); // 3. 组装货物记录批次号用时间戳序号生成 Goods goods new Goods(); goods.setGoodsNo(generateGoodsNo()); goods.setName(req.getName()); goods.setCategory(req.getCategory()); goods.setBatchNo(generateBatchNo()); goods.setQuantity(req.getQuantity()); goods.setShelfId(target.getId()); goods.setInboundTime(new Date()); goodsMapper.insert(goods); // 4. 更新货架当前占用数量 shelfMapper.increaseCount(target.getId(), req.getQuantity()); // 5. 写库存流水存变动前后值 InventoryLog logRecord new InventoryLog(); logRecord.setType(1); logRecord.setGoodsId(goods.getId()); logRecord.setQuantity(req.getQuantity()); logRecord.setOperatorId(operatorId); logRecord.setBeforeQuantity(0); logRecord.setAfterQuantity(req.getQuantity()); logMapper.insert(logRecord); } }这段代码的关键是事务注解和货架分配策略。事务保证「插入货物后更新货架」时如果发生异常两条数据都不会落库货架推荐使用 Stream 的 min 找 current_count 最小的记录正是 2.2 节「空位优先」规则的直译。generateBatchNo 一般用 yyyyMMddHHmmss 三位随机数保证同秒入库的货物能区分批次先后。出库逻辑相对特殊不能简单地扣总数要逐批次扣。假设库里有三批 A 货物入库日期分别是 6 月 1 日、6 月 10 日、6 月 15 日出库 50 件时应先扣 6 月 1 日批次的库存不够再顺延第二批。Transactional(rollbackFor Exception.class) public void outbound(OutboundRequest req, Long operatorId) { // 1. 按先进先出取批次同品类下入库时间正序 ListGoods batches goodsMapper.findByCategoryOrderByInboundTimeAsc(req.getCategory()); int remaining req.getQuantity(); for (Goods batch : batches) { if (remaining 0) { break; } int deduct Math.min(remaining, batch.getQuantity()); // 扣减当前批次库存 goodsMapper.decreaseQuantity(batch.getId(), deduct); // 写流水记录每次批次扣减入库时间最早的先扣 writeOutboundLog(batch, deduct, operatorId); remaining - deduct; } if (remaining 0) { throw new BusinessException(库存不足仅能出库 (req.getQuantity() - remaining) 件); } }这段逻辑里有个隐蔽问题如果批次列表里有一条记录 quantity 为 0比如之前已经被并发出库扣完了当前实现会直接把 0 作为可扣减数量处理不影响结果但会多写一条无意义流水。更稳妥的做法是在查询时加WHERE quantity 0条件过滤空批次这也是性能无关但逻辑严谨度相关的细节答辩时可以说出来加分。3.3 定时预警与权限控制把「智能」落到规则引擎和任务调度「智能」这个点在实现上可以分为两个部分一是库位推荐已在上文落进代码二是库存预警与超期处理。这里我用 Spring 自带的 Scheduled 注解实现定时任务不引入 Quartz 框架因为系统只有一个任务维度——每天零点扫描库存数据。Component RequiredArgsConstructor public class StockAlertTask { private final GoodsMapper goodsMapper; private final AlertRecordMapper alertMapper; /** * 每天 0 点执行扫描低库存与超期批次 */ Scheduled(cron 0 0 0 * * ?) public void scanStockAlert() { // 1. 低库存预警数量低于阈值的批次 ListGoods lowStockList goodsMapper.findBelowThreshold(20); lowStockList.forEach(g - alertMapper.insert(g.getId(), 低库存, 当前库存 g.getQuantity() 低于阈值 20) ); // 2. 超期预警入库超过 90 天的批次 Date thresholdDate DateUtils.addDays(new Date(), -90); ListGoods expiredList goodsMapper.findBeforeDate(thresholdDate); expiredList.forEach(g - alertMapper.insert(g.getId(), 超期, 入库时间超过 90 天) ); } }定时任务写完后别忘了在启动类上加 EnableScheduling 注解否则任务不会执行。这是排查时最容易漏的一步代码写得没错就是没扫描到启动开关。库存预警阈值 20 和超期天数 90 建议做成系统配置项存到数据库配置表而不是硬编码在代码里虽然实现时多一个查询步骤但答辩时「可配置化」是个设计亮点。4. 前端与交互Vue 项目搭建到联调的完整路线4.1 Vue 项目的目录与四个核心页面先搭骨架再填组件前端我用 Vue 2 Element UI 这套成熟组合。项目创建用 Vue CLI 或 Vite 均可目录组织建议按功能拆分而不是按页面类型拆分src/ ├── api/ # 所有后端接口的 axios 封装 │ ├── inventory.js # 出入库相关接口 │ ├── shelf.js # 货架管理接口 │ └── user.js # 登录与用户接口 ├── router/ # 路由配置含权限守卫 ├── store/ # Vuex存用户信息和全局状态 ├── views/ │ ├── Dashboard.vue # 仓库总览看板 │ ├── Inbound.vue # 入库操作台 │ ├── Outbound.vue # 出库操作台 │ └── StockQuery.vue # 库存查询与入库记录 └── utils/ └── request.js # axios 实例与拦截器四个核心页面覆盖了无人仓库的所有场景Dashboard 展示货架占用率、库存总量和最近预警Inbound 和 Outbound 是自助操作的入口业务员扫码或输入货物编号即可StockQuery 是查库存与流水的地方。看板页有一个高频交互——库位状态可视化我用 Element UI 的 Table 组件加自定义 class 实现货架当前占用率超过 80% 的行标红低于 30% 标绿让「空位在哪」一眼可见。4.2 axios 请求封装与跨域配置联调时的两个关键卡点前后端联调第一个翻车点往往是跨域。Vue 开发服务器默认跑在 8080SpringBoot 跑在 9090两个端口不同浏览器会拦截响应。前端侧的常见做法是用 Vite 或 webpack-dev-server 的代理把 /api 前缀转发到后端绕开跨域后端侧的兜底写法是配置 CORS 过滤器。// src/utils/request.js axios 实例封装 import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: /api, // 开发环境走代理生产环境走 Nginx 转发 timeout: 10000 // 10 秒超时防止接口卡死无响应 }) // 请求拦截器自动附带登录令牌 service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) // 响应拦截器统一处理业务码与登录失效 service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.msg || 请求失败) return Promise.reject(new Error(res.msg)) } return res }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } Message.error(error.message || 网络异常) return Promise.reject(error) } ) export default service跨域与请求封装两者要配合开发阶段用代理解决跨域可以让 axios 的 baseURL 直接写成相对路径/api部署时后端接口也不暴露真实地址安全性和可维护性都好。后端 CORS 配置是兜底我一般只在后端开发环境开启上线前关掉。拦截器里的 401 跳转很实用登录过期时用户不再看到满屏报错而是被自动送回登录页。这个细节对演示体验影响很大答辩时不希望当场被评委看到红色报错弹窗。4.3 出入库操作台的交互如何让操作员在屏幕上三步完成存取微信支付宝上操作「扫码-确认-提交」三步走就是无人物流的交互标尺。出入库操作台也按这个节奏设计。入库页面的流程是操作员输入货物编号前端自动带出名称和品类系统调用货架推荐接口返回推荐库位操作员核对数量后点「确认入库」。出库页面则复杂一点输入货物编号后前端先调库存查询接口展示当前有哪些批次、每批多少件再输入出库数量前端做一次「可用总量」校验避免提交后因库存不足被后端驳回。关于出库交互有一个设计细节后端返回批次列表后前端不要把「先进先出」的批次顺序打乱展示。最常见的坑是按数量排序或按随意顺序渲染操作员看到的第一行不是最早批次就容易现场提问时答不上来。我一般让后端返回时就标好inbound_time前端 Table 组件直接按时间升序排列并在每行加「建议优先出库」的文字标识。5. 从源码到演示六个常见坑的排查记录5.1 SpringBoot 版本与学生电脑的 JDK 不匹配启动即失败现象mvn spring-boot:run 启动时报Unsupported class file major version下载的源码包在本地就是起不来。原因SpringBoot 2.x 与 3.x 对 JDK 版本要求不同3.x 强制要求 JDK 17而很多毕设环境还是 JDK 8。标题里没有写版本信息所以拿到源码后第一件事是看 pom.xml 里的 parent 版本定义。解决pom.xml 里 spring-boot-starter-parent 版本是 2.7.x 就用 JDK 8 或 11是 3.x 就装 JDK 17。强烈建议在 IDEA 里给项目单独指定 JDK 版本不要改系统环境变量免得影响其他项目。5.2 MySQL 8 的时区与驱动问题现象后端启动失败报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized或者连接能建立但中文乱码。原因MySQL 8 的默认时区与 JDBC 驱动不一致连接串里没有指定 serverTimezone 和 characterEncoding。解决JDBC URL 写成统一格式jdbc:mysql://localhost:3306/warehouse?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrueallowPublicKeyRetrieval 参数是 MySQL 8 的专属坑不加它有时会报 Public Key Retrieval is not allowed。这是我在多个环境里踩出来的固定组合直接复制可用。5.3 前端「代理失效」玄学地址没改对接口 404现象后端接口用 Postman 测试全通前端页面请求却 404浏览器 Network 面板里请求地址是http://localhost:8080/api/xxx。原因vue.config.js 里 devServer.proxy 的 target 配错或没触发。最常见的问题是 axios baseURL 写的是http://localhost:9090这等于绕过了代理直接跨域请求又或者代理只匹配/api而实际请求路径是/inbound/list。解决前端所有请求统一以/api开头代理配置写成// vue.config.jsVue CLI 项目 module.exports { devServer: { port: 8080, proxy: { /api: { target: http://localhost:9090, changeOrigin: true, pathRewrite: { ^/api: } } } } }pathRewrite 的作用是把/api/inbound/list转发成/inbound/list注意后端RequestMapping的路径里不能带/api前缀否则要多一层拼接。5.4 定时任务不执行翻了半天代码发现没开开关现象数据库里已经插入低于阈值的库存数据但预警记录表一直为空Scheduled注解看起来没问题。原因Spring Boot 的定时任务默认是不启动的必须在启动类加EnableScheduling。这个开关藏在注解里新手经常忘记。解决主类上加注解后重启即可。另外调试时把 cron 表达式改短一点验证执行逻辑比如0 */1 * * * ?每分钟跑一次验证完再改回每日执行。5.5 打包后的 Vue 页面放进 SpringBoot 后白屏现象前端npm run build生成的 dist 目录拷进src/main/resources/static启动后端后打开首页白屏控制台报找不到 JS 文件。原因Vue Router 用的是 HTML5 history 模式时刷新/inbound这类非根路径后端没有对应路由返回 404另外静态资源路径是绝对路径如果应用没部署在根路径下就会找不到。解决两个方案选一个。方案一是把 Vue Router 改为 hash 模式URL 变成/#/inbound刷新不会发请求方案二是保持 history 模式在后端写一个 fallback controller把非/api的路径都转发到index.html。毕设演示建议直接用 hash 模式少一个配置点。5.6 演示现场数据库连接失败现象答辩或演示时打开系统列表页全部空白后端日志报Communications link failure。原因数据库服务没启动、端口被占用、或者账号密码与配置文件不一致。三个原因里前两个最常见。解决做一个「演示前检查三步走」确认 MySQL 服务在任务管理器或net start里显示运行用telnet 127.0.0.1 3306验证端口通不通直接在后端日志中确认数据源连接成功再打开页面。强烈建议把这三个动作做成习惯每次演示前固定执行比你临时查半天日志靠谱得多。6. 让答辩认出「好工程」四条验证路径与一个加分技巧系统跑通之后下一步不是写论文而是验证设计和寻找演示漏洞。我会按四条路径做验收每一条都对应评委可能追问的设计点。第一条路径是业务闭环验证从空库状态出发连续入库三种货物、再出库检查货架占用数、库存流水、批次扣减顺序是否与预期一致。重点看先进先出分别入库两批同品类货物后出库看系统扣的是不是第一批。第二条路径是异常路径验证故意提交超出库存数量的出库看提示是否友好停用一个货架后再入库该品类看系统是否跳过停用货架用普通操作员账号尝试删除货架基础数据看权限是否被拦截。这些异常场景才是「无人」系统最需要展示的价值点。第三条路径是数据可视化验证打开 Dashboard 看板确认入库后货架占用率图表即时刷新预警记录出现低库存条目。看板是评委对系统第一印象的来源数据不同步会直接暴露前后端联调粗糙。第四条路径是部署文档可复现验证换一台干净电脑按 README 从零部署能独立走通就是合格的交付。一个隐藏加分技巧是把部署过程录屏答辩现场不能保证网络环境但提前录好的启动演示可以规避环境风险。这里需要提醒一句视频演示只能作为补充现场启动成功始终是基本功。把这几轮验证的坑补进论文和演示文稿答辩时你讲的不再是「系统有什么功能」而是「系统怎么保证不犯错」——这个视角的分水岭会让评委认为你真的理解工程而不是只会调代码。我把这个习惯保留到了工作以后每上线一个模块先按用户路径把异常场景全部走一遍再谈新功能。希望帮到你。本文还有配套的精品资源点击获取