SpringBoot+Vue+MySQL车间管理系统毕设实战指南

又到一年毕设季，后台收到很多同学来问同一个问题：想做一套工厂车间管理系统，技术栈到底怎么选？我给的建议基本是同一套：SpringBoot + Vue + MySQL。这三样组合在一起，放在车间管理系统这个场景上，几乎就是毕设和课设里的“稳妥牌”。前后端分离、代码层次清晰、就业市场认可度高，而且网上资料和现成案例都很多，踩坑成本低，答辩风险也小。这篇文章我就把这个系统从选型逻辑到模块设计、从环境搭建到跑通联调、再到答辩准备的完整过程整理出来，给正准备动手或者已经卡在某个环节的同学一份能直接抄作业的路线。

1. 为什么是SpringBoot+Vue：选型逻辑与设计思路

1.1 前后端分离到底香在哪

先聊一个很多新人没真正想明白的问题：为什么现在做管理系统几乎默认前后端分离，而不是像以前那样用JSP、Thymeleaf直接在后端写页面？

最核心的原因是职责分离。后端只负责提供接口和数据，前端只管页面渲染和交互，两者通过JSON通信。这意味着前端工程师和后端工程师可以并行开发，互不阻塞。对于毕设来说，单兵作战虽然不存在“并行开发”的团队问题，但分离带来的代码组织上的清晰度是实打实的：后端是一套纯接口工程，前端是一个纯页面工程，目录结构、调试方式、部署方式都更加直观。

从答辩和面试角度讲，前后端分离也是加分项。面试官看到你用过SpringBoot + Vue，至少能确认你理解RESTful接口、跨域、Token认证、Axios请求拦截、路由守卫这些现代Web开发的基础概念。这些东西在传统JSP项目里是很难体现出来的。

另一个现实因素是资源多。SpringBoot和Vue的教程、踩坑记录、组件库、开源项目数量巨大，遇到任何问题都能搜到解决方案。毕设周期本来就紧，选一个资料丰富的技术栈，等于给自己留了后路。

1.2 车间管理系统到底在管什么

很多同学接到“车间管理系统”这个题目后，第一反应是：车间里要管的东西太多了，从哪里下手？这里我建议用“角色-业务”两条线去拆需求。

先看角色。一个典型的工厂车间里，有管理员、计划员、车间主任、班组长、操作工这几类人。不同角色关注的数据不一样：管理员关心整体运行状况，计划员关心工单下达，班组长关心任务分配和报工，操作工关心自己今天干什么活。你的系统里如果没有角色区分，所有人看到一样的菜单，那这套系统就只是“增删改查”的堆砌，答辩时很容易被问住。

再看业务主线。车间生产最核心的链条是：接到生产计划 → 生成工单 → 派工到班组/个人 → 领料 → 加工/组装 → 报工 → 质检 → 入库/交付。围绕这条主线，延伸出设备管理（设备台账、保养、维修）、物料管理（库存、出入库）、人员管理（考勤、绩效）、数据统计（产量、合格率、设备利用率）。

我把常用的功能模块整理成一张表，做需求设计时直接对着勾选就行：

毕设不是企业ERP，不需要做全做深，以上模块里挑4到6个核心模块，把业务逻辑做完整、数据流转打通，就已经是中等偏上的水平了。

1.3 数据库表设计：先把地基打牢

系统跑不跑得顺，一半看表设计。车间管理系统的核心表大概是这些：

• 用户表（sys_user）：用户ID、用户名、密码、姓名、手机号、角色ID、车间ID、状态
• 角色表（sys_role）：角色ID、角色名、角色编码、备注
• 工单表（work_order）：工单号、关联计划ID、产品名称、数量、计划开始/结束时间、状态、班组长ID、车间ID
• 生产计划表（production_plan）：计划编号、产品ID、计划数量、计划周期、状态
• 设备表（device）：设备编号、设备名称、型号、所属车间、状态、启用日期
• 设备保养记录表（device_maintenance）：保养ID、设备ID、保养类型、保养日期、下次保养日期、负责人、备注
• 物料表（material）：物料编号、物料名称、规格、单位、安全库存、当前库存
• 出入库记录表（material_record）：记录ID、物料ID、类型（入库/出库）、数量、关联工单ID、操作人、时间
• 质检记录表（quality_check）：质检ID、工单ID、产品ID、检验数量、合格数量、不良原因、质检员、检验时间

表设计里有个很重要的原则：状态字段用数字字典，不要用中文文本。比如工单状态用0待下达、1生产中、2已完工、3已质检、4已关闭，具体含义放到代码常量类或字典表里解释。原因很简单，数字存储效率高、便于排序和筛选，而且改状态显示名称时不需要改数据。同样的道理，性别、设备状态、物料类型等字段都建议这么做。

另外注意外键关系。工单表要关联计划ID和班组ID，出入库记录要关联物料ID和工单ID，质检记录要关联工单ID。在物理外键上我建议不加约束，只保留逻辑关联，理由在后面“常见问题”里讲。

2. 核心模块与功能拆解（交互逻辑与代码落点）

2.1 登录认证与权限控制

登录这块是毕设答辩提问的高频区，一定要搞清楚原理，不要只会调接口。

前后端分离项目里，传统的Session方案不太合适，因为跨域时Cookie的携带和共享比较麻烦。主流做法是Token认证，通常用JWT（JSON Web Token）。流程是这样的：用户输入账号密码，后端校验通过后生成一个包含用户ID和角色信息的Token返回给前端；前端把Token存到localStorage或Vuex/Pinia里；之后每次请求，前端在请求头加上Authorization: Bearer <token>；后端写一个拦截器，对需要认证的接口先解析Token，校验通过才放行。

JWT的代码逻辑不复杂，核心就是生成和校验两部分。生成时你可以设置过期时间，比如2小时或24小时，毕设场景24小时比较省事，用户不用老重新登录。校验时把Token里的用户信息取出来，放到请求上下文里，后面的Controller就能直接用。

前端对应的要做两件事：一是在Axios请求拦截器里统一加Token，二是在Vue Router里写全局前置守卫，判断有没有Token，没有就跳转到登录页。这两个点做出来，答辩时就可以说“我实现了前后端联动的权限控制”，这比只说“我在后端加了拦截器”的层次高很多。

角色权限最简做法是：登录后把角色编码存到Token里或者单独存一份，前端根据角色控制菜单显隐，后端接口根据角色控制访问权限。比如操作工角色只能查看自己的工单和提交报工，管理员可以调用所有接口。后端做权限校验的方式很多，可以用Spring Security + JWT，也可以用Shiro，也可以用最基础的拦截器手动判断。毕设级别用拦截器手动判断完全够，而且容易讲清楚。如果项目代码里已经集成了Spring Security，那就把它的过滤链和JWT的整合逻辑弄明白，答辩时能讲出“我是基于什么安全框架做的”就更好了。个人建议：时间紧就用手写拦截器，想加分就上Spring Security。

2.2 工单管理与生产状态流转

工单是整个车间系统的业务中枢，几乎所有模块都和它有关联，所以工单的状态流转设计直接决定这个系统的业务完成度。

我先说一下工单的常见生命周期：

待下达 → 生产中 → 已完工 → 已质检 → 已关闭

其中“已质检”之后还可能派生出“不合格返工”而回到“生产中”。状态流转在代码里怎么实现才不容易出Bug？关键是不要让前端随便传一个状态值给后端改。

正确的做法是：后端提供状态流转的专门接口，比如updateStatus(id, targetStatus)，接口内部先判断当前状态是否允许流转到目标状态，允许才执行更新。比如待下达的工单不能直接跳到已质检，必须经过生产中。这样数据永远沿着合法的路径走，不会出现“一个工单还没生产就有了质检记录”这种脏数据。

工单模块除了状态之外，还有几个容易忽略但很重要的细节：

• 工单号要唯一且有一定的业务含义，比如WO20240615001表示2024年6月15日的第001号工单。直接用数据库自增ID当工单号，答辩时会被问“这个编号有什么业务含义”，不太好答。
• 报工时要记录完成数量、报废数量、工时，这些数据是后续统计模块的数据来源。
• 工单和生产计划、派工班组、物料领用记录之间的关联要打通。比如查看工单详情时，能看到这个工单领了哪些物料、质检结果是什么，这才叫“系统”，而不是各模块之间的数据孤岛。

2.3 设备状态与物料库存管理

设备和物料虽然是辅助模块，但它们最能体现“车间管理系统”和“普通增删改查系统”的区别。

设备管理的核心不是“设备档案的增删改查”，而是状态跟踪。设备状态一般有：运行、停机、维修、保养。每个状态变更都应该有记录，比如停机要记录原因，维修要关联维修工和维修费用。另外保养计划是很容易出彩的亮点：每台设备设置保养周期（比如运行500小时或每30天），系统根据上次保养日期自动计算下次保养日期，在主页面或首页看板里提示“3台设备即将到期保养”。这个功能实现难度不高，但非常贴近真实车间场景，答辩时能讲出业务价值。

物料管理的关键是库存的准确性和操作的规范性。出入库操作必须成记录，出库要关联到具体的工单号，这样才能跟踪“这批物料用到了哪个工单”。库存扣减时需要注意并发问题：两个工单同时领用同一个物料，库存会不会被扣成负数？最简单的方案是在更新库存的SQL语句里加条件判断：UPDATE material SET stock = stock - #{num} WHERE id = #{id} AND stock >= #{num}，这样即使并发请求过来，数据库层面也能兜住，避免超扣。另外出入库操作和库存更新要放在同一个事务里，保证要么都成功、要么都回滚，这一点在讲“数据一致性”的时候是很好的素材。

2.4 数据可视化看板

没有任何一个工厂领导会满足于只看表格数据，所以一个车间管理系统里必须有一个图表看板，这也是毕设视觉层面的加分项。前端用ECharts，这是目前最常用的图表库。

看板一般放四个经典图表：

• 产量趋势图：折线图，按日期统计每天的完工数量
• 工单完成率：饼图或环形图，统计已完成工单占全部工单的比例
• 设备利用率：柱状图，统计每台设备的运行时间占比
• 质检合格率：折线图或柱状图，统计每个批次的合格率

这些图表的数据来源是后端统计接口，SQL写法上有一个常见套路：按日期分组统计。比如产量趋势的SQL大致是：

SELECT DATE(complete_time) AS work_date, SUM(finish_quantity) AS total_finish FROM work_order WHERE complete_time IS NOT NULL GROUP BY DATE(complete_time) ORDER BY work_date

前端接到这个数据后，把日期字段映射到X轴，数量字段映射到Y轴，ECharts的配置项里设置好xAxis、yAxis和series就能渲染出来。这里有一个容易踩的坑：MySQL的日期函数在不同版本里写法有差异，5.x和8.x对DATE()的处理基本一致，但如果你用了DATE_FORMAT(complete_time, '%Y-%m-%d')，要注意大小写和格式串的写法，错了查半天。

看板的意义不仅在于好看，更在于它是前面所有业务模块的数据汇总。能把这个讲清楚，答辩时就能回答“你这个系统的数据价值体现在哪里”。

3. 从零跑通整套项目：环境配置与启动实录

3.1 环境准备清单

先把手上的环境准备好，版本选择很关键，选错了后面各种坑。我列一份经过实测的版本组合：

这里重点提醒：如果你拿到的项目是Vue2 + Element UI，一定要用Node 14或16。之前有同学用了Node 18，结果node-sass编译直接失败，折腾了一晚上。Vue3项目用Node 16或18问题不大，但保险起见还是16。

数据库可视化工具推荐Navicat或者免费的DBeaver。Navicat方便但需要授权，DBeaver免费且功能够用，用哪个都行，关键是能看清表结构和数据。

3.2 数据库初始化与后端启动

拿到一套源码，先不要急着启动，按顺序做这几步：

第一步，在MySQL里新建一个数据库，比如factory_db，字符集选utf8mb4，排序规则选utf8mb4_general_ci即可。为什么要用utf8mb4？因为UTF-8在MySQL里存不了某些特殊字符（比如emoji和生僻字），utf8mb4是完整的四字节UTF-8，是现在的标准选择。

第二步，导入SQL脚本。用Navicat或命令行执行项目里提供的factory_db.sql文件。导入后检查核心表的数据是否齐全，特别是用户表里有没有预设账号，比如admin/admin123这样的初始账号。如果没有预设账号，你自己得先手动插入一条用户记录，否则登录都进不去。

第三步，修改后端配置文件application.yml。重点关注这几个配置项：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/factory_db?useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true&characterEncoding=utf-8 username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver

URL里的参数不是随便写的：useSSL=false是关闭SSL连接，避免8.0版本的SSL握手报错；serverTimezone=Asia/Shanghai是设置时区，不然日期时间会相差8小时；allowPublicKeyRetrieval=true是解决MySQL 8.0的Public Key Retrieval异常。这三个参数在MySQL 8.0下经常会遇到，属于最经典的坑。

第四步，启动后端。两种方式：在IDEA里直接运行主类，或者在项目根目录执行mvn spring-boot:run。启动成功的标志是看到Spring Boot的启动日志，内嵌Tomcat默认端口8080。如果报端口被占用，在配置里改端口，或者找到占用进程关掉。Windows下查出占用端口的命令很方便：

netstat -ano | findstr 8080 taskkill /PID 进程号 /F

后端启动后，可以先用浏览器或Postman访问一个接口验证，比如http://localhost:8080/api/captcha或者任意一个无需登录的接口，能看到JSON返回说明后端基本正常。

3.3 前端依赖安装与启动

前端的启动坑比后端多，很大一部分栽在依赖安装上。

先确认你用的是什么包管理工具，一般是npm。安装依赖前强烈建议把npm源切换到国内镜像，不然几十上百个依赖要等到天荒地老：

npm config set registry https://registry.npmmirror.com

然后在项目前端目录（通常是frontend或vue-admin文件夹）下执行：

npm install

这一步是装Node依赖，如果报node-sass相关的错，基本就是Node版本太高，降版或者用npm install node-sass@版本号重装。

装完依赖后，启动前还有一个关键配置要检查：vue.config.js里的代理配置。因为前端开发服务器跑在8081或8080，后端接口跑在8080或别的端口，浏览器直接请求后端会跨域。开发环境最优雅的解决方式是配置代理：

module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

这样前端请求/api/login会被代理转发到后端http://localhost:8080/api/login，前端页面里不需要写死后端地址，也不用开启CORS。顺便说一句，前端项目里请求后端地址时，尽量用相对路径（以/api开头），不要写成http://localhost:8080/api/xxx这种绝对地址，否则部署上线时改起来非常痛苦。

启动命令：

npm run serve

启动成功后浏览器访问提示的地址，比如http://localhost:8081，能看到登录页说明前端正常。登录页如果能成功登录并跳转到首页，前后端联调就通了。

3.4 前后端联调与统一返回规范

前后端联调阶段，最怕的是两边各自为政，接口返回的数据格式五花八门。所以规范的统一返回体非常关键。

一个标准的统一返回体至少包含三个字段：

{ "code": 200, "msg": "操作成功", "data": {} }

后端封装一个Result类，成功时返回Result.success(data)，失败时返回Result.error(code, msg)。前端Axios拦截器统一处理后端返回：

service.interceptors.response.use( response => { const res = response.data if (res.code === 200) { return res } // 非200统一弹错误提示 Message.error(res.msg) return Promise.reject(new Error(res.msg)) }, error => { // 处理401等HTTP错误 Message.error('请求失败') return Promise.reject(error) } )

同时请求拦截器统一加Token：

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

这一套规范做好后，新增接口时大家只要照葫芦画瓢，几乎不会出现对接层面的问题。前端就不用每个页面重复写错误弹窗、Token处理这些样板代码，这也是联调效率提升的关键。

4. 毕设实战排坑：高频问题与排查技巧

4.1 数据库相关：90%的启动失败都在这

后端一启动就报错，十有八九是数据库连接问题。我按出现频率列几个典型场景：

• Public Key Retrieval is not allowed：MySQL 8.0默认使用caching_sha2_password认证，连接时需要在URL里加allowPublicKeyRetrieval=true，否则报这个错。加上就好。
• SSL connection error：8.0版本默认开SSL，本地开发不需要，URL里加useSSL=false。
• The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized：这是时区问题导致的乱码报错，URL加serverTimezone=Asia/Shanghai。
• 驱动类报错：ClassNotFoundException: com.mysql.jdbc.Driver。这是驱动版本和驱动类名不匹配导致的。5.x用com.mysql.jdbc.Driver，8.x用com.mysql.cj.jdbc.Driver。现在新项目基本都是8.x，如果你在pom.xml里看到mysql-connector-java版本是8.x，配置文件里写的却是com.mysql.jdbc.Driver，必报错。

这些坑我在帮别人排错时几乎每周都能遇到，一次记住，以后就能秒定位。

4.2 跨域与Token异常

前后端联调时最常见的是跨域报错：浏览器控制台出现Access to XMLHttpRequest at ... has been blocked by CORS policy。

跨域处理有三条路，开发环境最推荐代理（前面说的vue.config.js配置）；如果后端单独开启了CORS配置，也能解决；如果部署到Nginx，就在Nginx里做反向代理。三条路任选其一就行，同时开多个反而容易出奇怪问题。

Token相关的坑也有几个：

• 401无权限：后端拦截器校验Token失败。检查前端是否把Token放到了请求头，检查Token是否过期，检查拦截器的放行路径是否配置正确（登录接口、验证码接口必须放行）。
• Token拿到但用户信息取不到：后端在拦截器里把用户信息放到了request.setAttribute或请求上下文中，但Controller里取的位置不对。建议写一个工具类，统一提供“获取当前登录用户”的方法，避免各处重复解析Token。

4.3 依赖与环境的历史性难题

依赖问题的破坏力仅次于数据库，而且更难排查，因为它往往不是代码问题，而是环境问题。

Maven依赖下载慢，解决方案就是配阿里云镜像。在settings.xml里加：

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

配完后如果还有依赖版本冲突，比如NoSuchMethodError、ClassNotFound这类奇怪报错，优先检查是不是同一个依赖被引入了多个版本。IDEA里可以在Maven面板点击Show Dependencies查看依赖树，排查冲突很快。

前端依赖的坑主要是node-sass和Node版本不兼容。现在很多老项目还在用node-sass，但这个库已经停止维护了，对Node版本非常敏感。如果装不上或编译报错，建议把前端项目里的sass相关依赖换成dart-sass（对应npm包名就是sass），或者直接换Node版本。

另外一个实用工具是Vue Devtools插件，联调时用来排查Vue组件状态和数据流向非常方便。Vue2和Vue3的Devtools版本不同，装错了在浏览器里不显示，去对应版本的应用商店里装就行。

4.4 答辩追问：提前准备这些问题

答辩不是只看系统跑不跑得起来，核心是考察你有没有真正理解自己做的项目。根据我帮人模拟答辩的经验，下面这几个问题出现的频率最高：

1. “为什么选SpringBoot和Vue？”——答：SpringBoot简化配置和内嵌容器，适合快速构建微服务风格的接口；Vue生态成熟、组件化开发、开发效率高；前后端分离便于维护和扩展。
2. “权限是怎么控制的？”——答：前端通过路由守卫控制页面访问，根据角色动态渲染菜单；后端通过拦截器校验Token，并在接口层校验角色权限。双端联动。
3. “数据库表之间是什么关系？”——答：主表和关联表之间通过逻辑外键关联，举一两个例子说明，比如工单表关联生产计划表、物料记录表关联物料表和工单表。
4. “库存扣减的时候怎么保证数据一致？”——答：使用事务保证出入库记录和库存更新要么同时成功要么同时失败；更新库存时加条件判断防止扣成负数。
5. “系统的扩展点在哪里？”——答：比如可以引入消息队列做异步通知，引入Redis做缓存，增加数据导出功能，集成第三方登录等。

这五个问题提前准备好，答辩基本稳了。

5. 从跑通到加分：学习路线与二次开发建议

5.1 给毕设加分的四个小改造

如果你时间有余，强烈建议在原项目基础上做几个“小而美”的改造，性价比非常高：

一是引入Redis做缓存。比如把字典数据、用户Token、热点统计结果缓存起来，减少数据库压力。代码改动不算大，但能在答辩时说“我考虑了系统性能优化”，一下子把层次拉高了。

二是用MyBatis-Plus替换原生MyBatis。MyBatis-Plus的单表CRUD和内嵌分页插件能让代码量减少一半以上。很多现代项目都在用，学到手对找工作也有帮助。前提是确保项目原本用的是MyBatis，如果是Spring Data JPA那就另说。

三是集成WebSocket做消息通知。比如工单被派发、设备保养到期时，系统能实时推送给相关用户。WebSocket在前后端分离项目里的应用是个不错的亮点。

四是增加Excel导入导出功能。后端用EasyExcel或POI实现工单、物料数据的导入导出，这是工厂系统里非常实际的需求。

5.2 从“会用”到“懂原理”的进阶路线

如果做完毕设后还想继续在这个方向深入，我给一条清晰的进阶路线。

第一阶段，深读源码。把你跑通的这个项目从头到尾读一遍，重点理解它的分层结构：Controller层接收请求、Service层处理业务、Mapper层访问数据库、Entity层映射表。搞清楚每个请求从进入到返回的生命周期。

第二阶段，看框架官方文档。SpringBoot的官方文档有明确的“Developing with Spring Boot”章节，Vue则有完整的教程。不用全看，看跟当前项目相关的部分即可，带着项目里的疑问去看，收获完全不一样。

第三阶段，扩展技术栈。往分布式方向加Redis、消息队列；往前端工程化方向加TypeScript、Vite、Pinia；往部署方向学Docker + Nginx + 云服务器。这些都是工厂车间管理系统后续自然的演进方向，也是简历上的加分项。

第四阶段，总结沉淀。把你做项目过程中遇到的问题、解决方案、设计思路整理成一篇文档放在GitHub上。面试聊项目时，能拿出一个规范的README和清晰的架构说明，说服力比说一百句“我熟悉SpringBoot”都强。

回到开头那个话题：为什么我一直推荐先用SpringBoot + Vue + MySQL把一套车间管理系统跑通？因为它覆盖了后端开发、前端开发、数据库设计、部署运维的完整链路，对毕设、对校招面试、对理解一个业务系统从零到一的过程，都有实实在在的帮助。我个人在实际做项目的体会是：不要一开始就想“我要做一个别人没做过的项目”，而是先跑通一个成熟的项目，再把里面的技术消化成自己的东西。这个过程走完，你会发现再去做任何管理系统的思路都会清晰很多。

最后再分享一个实打实的经验：代码里的注释和提交记录，一定要当成作品的一部分认真写。我见过很多系统功能做得不错，但代码里全是拼音变量名、没有一行注释、Git提交记录就一句“111”的项目，答辩效果大打折扣。反过来，一个功能普通但代码规范、文档齐全的项目，反而更容易拿到高分。因为评分老师看的不只是结果，更看重你的工程习惯和学习态度。这也算是在车间管理系统之外，你真正能从毕设里带走的东西。