说起中小企业设备管理我脑海里立刻浮现出某个制造厂设备科的工作台一面墙的文件夹、一堆随时可能被水泼到或弄丢的纸质台账、微信群里接龙式的报修信息以及月底才临时加班汇总的Excel表格。设备数量一旦超过几十台这套人工流程就开始失控了——同样的故障反复报修没人跟进、保养计划全凭老师傅记忆、备件库存永远对不上账。我做过几套类似的设备管理系统也帮不少同学把这类项目从课设打磨成真正能跑的业务原型所以这篇就把SpringBoot Vue MySQL这套组合从需求拆解到代码落地完整讲一遍。无论你是正在纠结毕设选题还是想给自家公司做个轻量管理工具这篇文章都可以直接当参考资料用里面没有空话全是能落地的设计思路和踩坑记录。1. 为什么中小企业需要一套设备管理系统——来自实际场景的痛点拆解设备管理在很多中小企业里长期处于没人管、管不清、想管没工具的尴尬状态。理解不了这个背景你做的系统就只是一堆增删改查页面答辩时也讲不出价值。所以先花点篇幅把业务痛点捋清楚后面设计功能模块时才不会跑偏。1.1 设备台账纸质记录带来的三不知问题我见过不少设备管理员你问他厂里一共有多少台设备他能说出大概数字但具体每一台的型号、购入日期、上次保养时间、所在位置他得翻半天纸质档案。这就是典型的三不知不知道设备的具体信息和状态、不知道设备分布在哪些部门和工位、不知道哪些设备已经临近报废或保养逾期。设备台账数字化是这个系统的地基。每一台设备从入库那一刻就应该有一个唯一的资产编号关联上设备类型、规格型号、所属部门、责任人、供应商信息、购入金额和日期。这些字段听着基础但等设备数量到了几百台你拿Excel做筛选和统计就会卡成幻灯片更别谈多人协作时的数据一致性了。1.2 维修与保养流程断档导致资产寿命缩短设备出故障了传统操作是现场工人打电话或者群里吼一声维修师傅凭记忆找排查记录修完了口头说一句好了。这个过程里会产生一堆问题故障描述不完整、派单没有记录、维修结果没人验收、同类故障反复出现但找不到历史数据。再说保养很多设备的保修条款里明确要求定期保养但实际操作中保养计划往往被排产压力挤掉。等到设备真正趴窝停机一查是保养没跟上厂商直接拒保那损失就大了。所以系统里的保养管理不能只是记录一次保养而要有周期生成下次保养计划的能力能提前提醒责任人。1.3 数据统计Excel管理的极限在哪里Excel不是不能用而是当操作人、负责人、审核人分散在不同部门时你根本分不清最新版本在谁手里。今天A改了同事B的台账明天C又拿旧表覆盖回去最后统计出来的设备完好率、故障率、维修费用谁都不敢拍胸脯说准确。系统化的核心价值不是省掉一张Excel表而是把设备相关的所有操作变成一条条有责任人、有时间戳、有状态流转的记录。后面做统计报表时这些记录就是可追溯的数据源任何一层数据存疑都可以往下钻取到原始工单。2. 技术栈选型SpringBoot Vue MySQL 组合的真实理由选技术栈不能光看流行要看项目定位和学习成本。SpringBoot Vue MySQL这套组合之所以常年霸榜课设和中小企业内部项目是因为它踩中了几个非常实在的点。2.1 前后端分离为什么是当下的主流如果是五年前SpringBoot直接返回Thymeleaf模板页面也行但现在的同学出去实习就业大部分团队已经全面转向前后端分离。前端Vue负责页面渲染和交互后端SpringBoot只提供JSON接口两边通过RESTful API通信。这套模式的好处是前端可以单独部署调试后端接口可以给小程序、App等多端复用招聘市场上对这套组合的认可度也高。对于学习来说前后端分离还能帮助你理清职责边界——前端只管拿到数据、展示数据、收集用户输入后端只管校验参数、处理业务逻辑、读写数据库。很多同学代码写得乱根本原因就是前后端逻辑混在一起数据库查询条件散落在页面代码里。项目一开始就按分离架构组织这个好习惯会受益很久。2.2 SpringBoot在课程设计和毕业设计中的优势SpringBoot选型最直接的理由是零配置起步。传统的SSM框架要写一堆XML配置文件光环境搭建就能劝退一大半人。SpringBoot内嵌Tomcat一个main方法就能启动配合Spring Data JPA或MyBatis-Plus数据库操作也不需要手写大量样板代码。对于设备管理系统这种典型的管理类应用业务逻辑集中在增删改查和状态流转上SpringBoot的单体架构完全够用还不需要为了用微服务而用微服务。更重要的是SpringBoot的资料极其丰富遇到问题搜一下基本都能解决——这在赶进度的课设阶段是巨大的隐性优势。2.3 MySQL选型与版本注意点MySQL是这个项目最稳妥的数据库选择开箱即用、社区工具生态成熟。值得提醒的是安装版本建议选5.7或8.0如果选8.0要注意驱动名称从com.mysql.jdbc.Driver变成了com.mysql.cj.jdbc.Driver时区参数也要显式指定serverTimezoneAsia/Shanghai否则连接时会报时区错误。另一个选型建议是数据库字符集统一设置为utf8mb4别用utf8。设备名称里难免有生僻字或特殊符号utf8mb4才是完整的Unicode实现这也是很多人在做导入导出功能时发现乱码的根本原因。3. 系统功能模块梳理从设备台账到故障闭环开始写代码之前先把功能模块画清楚。这套系统我建议划分成六个核心模块基本覆盖中小企业设备管理的所有高频场景。3.1 设备台账管理设备台账是全部业务的数据源头。列表页需要支持多条件组合筛选设备编码模糊搜索、设备类型下拉选择、使用部门筛选、当前状态筛选。每条设备记录的核心字段包括字段说明设备编码系统自动生成或按规则手工录入全局唯一设备名称/型号自然语言描述便于检索设备类型关联分类表支持树形结构所属部门/责任人明确归属考核有依据购入日期/金额用于资产折旧统计需要选型当前状态正常运行、待维修、维修中、已报废这里特别建议把当前状态做成系统的核心状态机后面所有模块都会引用它。3.2 设备保养计划保养模块不是简单记录我保养了,而是要能定义保养周期规则。比如某台空压机每运转500小时保养一次或者某条生产线每个季度的第一个周一做检查。系统根据上次保养日期和周期自动计算出下次保养日期在仪表盘上展示未来两周内到期的保养任务。实现时我建议单独建保养计划表和保养执行记录表计划表定义未来应该做什么执行表记录实际做了什么两个表通过设备编码和计划编号关联。这样既有前瞻性又有追溯性。3.3 巡检管理巡检更偏现场执行层。普通员工扫码或手动登记巡检结果记录内容包括设备运行是否正常、有无异常噪音、关键仪表读数、现场照片等。巡检记录表至少需要巡检人、巡检时间、设备编码、正常/异常状态、问题描述、建议处理方式。这里有一个实用设计巡检发现异常时系统自动生成一条报修工单草稿避免用户二次填写。这个联动逻辑在答辩时非常加分因为它体现了系统不是孤立的表单集合而是一个有状态联动的业务系统。3.4 报修与维修闭环报修模块是整个系统里逻辑最复杂、也最能体现工程设计能力的地方。一个完整的报修流程应该是报修人提交报修申请填写设备、故障现象、紧急程度维修班组接到工单进行派单或抢单维修人执行维修填写处理方式、更换配件、维修工时报修人确认维修结果工单闭环所有工单进入历史记录支持按设备、按时间段统计工单表必须有状态字段常见的取值有待派单已提交、维修中已接单、待验收已提交维修结果、已完成报修人确认、已撤销。3.5 备件管理备件管理很容易被忽略但维修模块一旦涉及更换配件就必须有库存数据支撑。备件表记录备件编码、名称、规格、安全库存量、当前库存量。维修工单里填写使用了哪个备件、用了几件系统就自动扣减库存低于安全库存时在仪表盘给出补货提醒。这样设计的价值在于维修工单不再只是描述故障填个结论而是和库存系统打通形成业务闭环。这比单独做一个备件CRUD高级得多。3.6 统计报表报表模块是让管理层愿意用这套系统的关键。建议提供四个核心图表设备状态分布饼图每月维修工单数量趋势折线图按部门/设备类型的故障率排行维修费用和备件消耗统计技术实现上这类统计不需要实时聚合每天凌晨或每次工单流转时更新汇总数据即可避免大表做复杂JOIN导致页面卡顿。后端提供聚合接口返回统计结果前端用ECharts绘制图表就行。3.7 角色与权限三类角色怎么划分权限模型建议采用最通用的RBAC。至少设置三类角色管理员全部权限包括用户管理、参数配置、数据导出设备管理员设备台账、保养计划、备件管理的读写权限普通用户只看设备信息可发起维修工单对自己的工单有查看权限权限粒度到按钮级会更专业前端用自定义指令控制按钮显隐后端用拦截器校验接口权限两层都做才能防止绕过前端直接调用接口的越权操作。4. 数据库设计八张核心表如何撑起整个业务数据库设计是这套系统里最不能节省时间的部分表关系设计好后面写业务逻辑会非常顺畅。我直接给出一套经过实战打磨的落地方案。4.1 核心表清单与关系表名用途关键外键sys_user用户表角色IDsys_role角色表—device_type设备类型表父类型ID树形device设备台账表类型ID、部门IDmaintenance_plan保养计划表设备IDrepair_order维修工单表设备ID、操作人IDinspection_record巡检记录表设备IDspare_part备件表—再建三张关联表工单与备件的关联表repair_order_part、维修记录操作日志表operation_log、保养执行记录表maintenance_record。整套下来十二张表左右张张有业务含义不多不少。4.2 设备表设计要点设备表是核心主表字段设计上除了基础信息一定要考虑扩展性。比如增加custom_field_json列存放一些非结构化自定义属性——不同类别的设备需要记录的参数是不一样的专门为每类设备建不同的表不现实用JSON字段可以灵活兼容。设备状态字段建议用TINYINT存数字枚举别直接存中文避免排序、统计时遇到编码问题。代码里对应一个常量类或枚举类页面上展示时再做映射。CREATE TABLE device ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, device_code VARCHAR(50) NOT NULL COMMENT 设备编码, device_name VARCHAR(100) NOT NULL COMMENT 设备名称, device_type_id BIGINT NOT NULL COMMENT 设备类型ID, model VARCHAR(100) DEFAULT NULL COMMENT 规格型号, department VARCHAR(100) DEFAULT NULL COMMENT 所属部门, manager VARCHAR(50) DEFAULT NULL COMMENT 负责人, purchase_date DATE DEFAULT NULL COMMENT 购入日期, purchase_price DECIMAL(10,2) DEFAULT NULL COMMENT 购入金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态: 0正常 1待维修 2维修中 3已报废, custom_field_json TEXT COMMENT 自定义扩展字段, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_device_code (device_code), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT 设备台账表;4.3 维修工单表状态机怎么落到数据库里维修工单表要能支撑完整的流程闭环状态流转是核心逻辑。字段上除了设备ID、故障描述、紧急程度还要有报修人ID、当前处理人ID、接单时间、完成时间、维修方案、验收结果。实际开发中状态机最容易犯的错是只在前端控制按钮和状态后端接口没有校验状态合法性。比如一个已经已完成的工单再次提交维修结果会导致时间线混乱。正确的做法是在Service层写状态流转方法每个方法开头先检查当前状态和期望状态是否匹配不匹配直接抛业务异常。orders表设计时再强调两点处理人字段存用户表ID而不是姓名这样可以避免重名问题需要显示姓名时再关联查询时间字段统一用DATETIME别用VARCHAR存字符串时间否则后续统计排序会出大麻烦。4.4 保养计划与执行记录两张表怎么做联动计划表定义计划执行表记录实际执行。计划表字段包括设备ID、保养周期类型按天数或按运行时长、周期值、上次执行时间、系统计算的下次执行时间、当前启用状态。当系统判定某个计划已到期需要生成保养待办提醒。考虑到中小企业不一定有完善的定时任务基础设施最简单的方案是不用定时器而是在用户登录后的仪表盘接口里实时查询下次执行时间 当前日期且未关闭的计划然后展示成待办。这种懒查询方案在数据量不大的场景下完全够用还省去了定时任务的心跳维护。5. 后端骨架实现从登录鉴权到报修流程的状态机后端这部分我挑四个最核心的骨架讲清楚它们是整套系统的技术底座。5.1 JWT 拦截器实现登录态设备管理系统不需要引入复杂的Spring Security因为它只是内部管理系统用JWT做无状态认证足够。设计思路用户登录成功后后端签发一个有效期两小时的JWT包含用户ID、用户名、角色编码前端把Token存到localStorage每次请求在HTTP头里带Authorization: Bearer {token}后端拦截器校验Token有效性解析出用户信息放到请求上下文里Token校验逻辑要特别注意Token过期时的处理不要只返回笼统的未认证建议返回明确业务码AUTH_EXPIRED前端收到后统一跳转登录页。5.2 统一返回结构与全局异常处理所有接口统一返回固定格式{ code: 200, message: success, data: {} }这个格式配合全局异常管理器能让Controller层代码非常干净业务逻辑里只需要把真实数据往Result里一放就行不用每个接口都写try-catch。业务异常的抛出方式建议定义自定义异常类BizException在Service里遇到设备状态不允许维修这类业务冲突时直接抛出由全局处理器统一包装成JSON返回。这样做的好处是Controller层不会因为异常处理代码而变得臃肿排查问题时日志里也能看到明确的业务错误码。5.3 设备报修流程的Service实现要点维修工单的Service是整套系统里最有含金量的代码段。我贴一下核心的状态流转片段Service public class RepairOrderServiceImpl implements RepairOrderService { Override Transactional(rollbackFor Exception.class) public void acceptOrder(Long orderId, Long operatorId) { RepairOrder order repairOrderRepository.findById(orderId) .orElseThrow(() - new BizException(工单不存在)); // 核心状态机校验 if (!OrderStatus.PENDING_DISPATCH.equals(order.getStatus())) { throw new BizException(当前工单状态不允许接单); } order.setStatus(OrderStatus.REPAIRING.getCode()); order.setHandlerId(operatorId); order.setAcceptTime(LocalDateTime.now()); // 同时联动设备状态让设备进入维修中 Device device deviceRepository.findById(order.getDeviceId()).orElseThrow(); device.setStatus(DeviceStatus.REPAIRING.getCode()); deviceRepository.save(device); repairOrderRepository.save(order); // 操作日志 operationLogService.record(工单接单, orderId, operatorId, 工单 order.getOrderNo() 被接单设备进入维修中状态); } }这段代码里有两个要点一是Transactional必须加上工单状态更新和设备状态更新要保证原子性事务里谁失败就一起回滚二是操作日志要配合写入这是管理系统的审计需求也是答辩时能说的亮点。5.4 MyBatis-Plus还是Spring Data JPA这两个ORM我实际都用过各有各的顺手之处。我的建议是如果更熟悉SQL或者需要频繁做多表复杂统计查询选MyBatis-Plus分页插件和代码生成器都很省事如果希望实体层更干净关联关系依赖框架自动处理选Spring Data JPA但要注意一点不管选哪个复杂统计报表不要用ORM去硬拼建议直接写原生SQL或使用MyBatis-Plus的selectMaps返回Map结构再在Service层组装成前端需要的格式。ORM能帮的是对象之间的增删改查聚合分析永远是SQL的主场。6. 前端工程化实践Vue3 Element Plus 的页面组织方式前端部分我默认使用的是Vue3 Vite Element Plus的组合。Vue2虽然还有存量项目但新启动的课设项目我强烈建议直接上Vue3生态已经完全成熟。6.1 项目脚手架与目录结构用Vite创建Vue3项目就行比Webpack构建快不少npm create vitelatest device-web -- --template vue推荐的目录组织方式src/ api/ // 按模块拆分的接口请求 router/ // 路由配置 store/ // Pinia状态管理存用户信息和权限 views/ // 页面组件 components/ // 全局复用组件 utils/ // axios实例、公共工具函数目录清晰的好处是答辩或者后续接手的人不用到处找代码这也是专业工程团队的基本要求哪怕课设也应该按这个规范来。6.2 路由与权限控制路由配置里把需要登录才能访问的页面统一放在一个嵌套路由下套一个Layout组件。前端权限控制做两层第一层是路由守卫检查本地Token是否存在没有就跳登录页router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.public) { next() } else if (token) { next() } else { next(/login) } })第二层是按钮级权限封装一个v-permission自定义指令根据用户角色判断按钮是否渲染。不要以为前端做了权限就万事大吉后端接口必须也做权限校验。前端控制只是用户体验层面的优化真正的数据安全都在后端拦截器里。6.3 axios封装与跨域处理axios实例统一封装核心配置包括请求拦截器里附加Token、响应拦截器里统一解析后端返回格式遇到code ! 200时用Message组件提示错误信息遇到401跳转登录页。开发环境跨域最简单的方案是在Vite的server.proxy配置里做代理server: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样做的好处是前端请求直接写/api/xxx开发时Vite自动转发到后端服务生产环境再把后端接口路径配成同域即可不需要后端做CORS跨域配置干净利落。6.4 核心页面设备列表与维修工单怎么设计交互设备列表页是整个系统的门面。建议用Element Plus的el-table展示数据配合顶部的筛选表单和分页组件。这里分享一个优化细节大数据量下列表加载慢后端接口一定要分页前端翻页时通过URL参数保存当前页码和筛选条件用户编辑完一条记录返回列表还能停留在刚才的位置这个小细节在实际使用中很受欢迎。维修工单页面的交互设计核心是状态驱动操作根据工单状态动态渲染可执行的操作按钮。待派单状态显示接单按钮、维修中显示提交维修结果按钮、待验收状态显示验收通过/驳回按钮。这种交互方式不会让用户面对一堆无意义的按钮业务逻辑也一目了然。7. 跑通项目的关键细节与毕设答辩避坑指南最后这部分是干货中的干货全都是我在实际部署和帮同学调试项目过程中遇到过的典型问题。7.1 版本兼容问题汇总我把常见的版本坑整理成一张表照着检查能省半天时间组件推荐版本常见坑JDK8或11别一上来用21的测试版部分框架可能不兼容Spring Boot2.7.x或3.x3.x要求JDK17注意对应关系MySQL5.7或8.08.0驱动类名变更时区参数必须设置Node.js18部分Vite版本对低版本Node不友好Vue3.4保持npm包版本一致别混装Vue2和Vue3组件7.2 前后端联调的常见报错后端起了服务前端页面上却拿不到数据这类问题占我平时答疑的一半。最容易犯的三个错前端请求路径和Controller的RequestMapping不一致多了一个前缀或少了一个/数据格式对不上后端返回的是一个Date对象前端直接渲染成莫名其妙的时间字符串需要手动格式化跨域配置缺失或者Nginx反向代理配置有误导致请求发出去后浏览器报CORS错误排查技巧先开浏览器F12看Network面板确认请求状态码和响应内容再从后端日志看有没有请求进来这样能快速定位问题出在前端还是后端。7.3 答辩/课设验收的重点准备如果这个项目是用于毕业设计或课程设计答辩时要展示的深度和侧重点和实际交付不太一样。面试官和评审老师通常会关注三个层次的问题第一层是这个小项目你都做了哪些功能——这个只需要把功能模块演示一遍就行。第二层是你为什么要这样设计——比如为什么选MySQL不选Oracle、为什么设备状态要单独维护、为什么工单要分状态流转这些必须要有清晰的业务理由。第三层是遇到某个具体问题你怎么解决的这时候最加分的就是讲真实的调试经历比如当时你查了一个下午终于发现是参数类型不符这类细节最能证明项目是你自己亲手写出来的。7.4 从课设到真正可用的差距说实话大部分课设级项目距离企业内部真正投入使用还有一段距离主要是缺这几个能力多租户支持多个分公司数据隔离、消息通知工单流转时微信或短信提醒、文件上传巡检照片和维修报告附件、在线导出报表Excel导出功能。但这些差距恰恰是你可以继续扩展的方向。如果答辩时能主动说下一步我计划在工单流转时引入消息提醒机制评审的印象分会明显不一样。我自己在练习这个项目时还有一个体会不要为了追求功能的多少而忽略流程的闭环。一个从报修到维修到验收全程可追踪的工单流程比十个只做了增删改查却互不关联的功能都更有价值。把业务讲透、把状态流转做严谨这套系统的含金量就达到了。 
长河君 · 2026/10/18 5:22:49 · 阅读 1.2k SpringBoot+Vue+MySQL实战：中小企业设备管理系统设计与实现
说起中小企业设备管理我脑海里立刻浮现出某个制造厂设备科的工作台一面墙的文件夹、一堆随时可能被水泼到或弄丢的纸质台账、微信群里接龙式的报修信息以及月底才临时加班汇总的Excel表格。设备数量一旦超过几十台这套人工流程就开始失控了——同样的故障反复报修没人跟进、保养计划全凭老师傅记忆、备件库存永远对不上账。我做过几套类似的设备管理系统也帮不少同学把这类项目从课设打磨成真正能跑的业务原型所以这篇就把SpringBoot Vue MySQL这套组合从需求拆解到代码落地完整讲一遍。无论你是正在纠结毕设选题还是想给自家公司做个轻量管理工具这篇文章都可以直接当参考资料用里面没有空话全是能落地的设计思路和踩坑记录。1. 为什么中小企业需要一套设备管理系统——来自实际场景的痛点拆解设备管理在很多中小企业里长期处于没人管、管不清、想管没工具的尴尬状态。理解不了这个背景你做的系统就只是一堆增删改查页面答辩时也讲不出价值。所以先花点篇幅把业务痛点捋清楚后面设计功能模块时才不会跑偏。1.1 设备台账纸质记录带来的三不知问题我见过不少设备管理员你问他厂里一共有多少台设备他能说出大概数字但具体每一台的型号、购入日期、上次保养时间、所在位置他得翻半天纸质档案。这就是典型的三不知不知道设备的具体信息和状态、不知道设备分布在哪些部门和工位、不知道哪些设备已经临近报废或保养逾期。设备台账数字化是这个系统的地基。每一台设备从入库那一刻就应该有一个唯一的资产编号关联上设备类型、规格型号、所属部门、责任人、供应商信息、购入金额和日期。这些字段听着基础但等设备数量到了几百台你拿Excel做筛选和统计就会卡成幻灯片更别谈多人协作时的数据一致性了。1.2 维修与保养流程断档导致资产寿命缩短设备出故障了传统操作是现场工人打电话或者群里吼一声维修师傅凭记忆找排查记录修完了口头说一句好了。这个过程里会产生一堆问题故障描述不完整、派单没有记录、维修结果没人验收、同类故障反复出现但找不到历史数据。再说保养很多设备的保修条款里明确要求定期保养但实际操作中保养计划往往被排产压力挤掉。等到设备真正趴窝停机一查是保养没跟上厂商直接拒保那损失就大了。所以系统里的保养管理不能只是记录一次保养而要有周期生成下次保养计划的能力能提前提醒责任人。1.3 数据统计Excel管理的极限在哪里Excel不是不能用而是当操作人、负责人、审核人分散在不同部门时你根本分不清最新版本在谁手里。今天A改了同事B的台账明天C又拿旧表覆盖回去最后统计出来的设备完好率、故障率、维修费用谁都不敢拍胸脯说准确。系统化的核心价值不是省掉一张Excel表而是把设备相关的所有操作变成一条条有责任人、有时间戳、有状态流转的记录。后面做统计报表时这些记录就是可追溯的数据源任何一层数据存疑都可以往下钻取到原始工单。2. 技术栈选型SpringBoot Vue MySQL 组合的真实理由选技术栈不能光看流行要看项目定位和学习成本。SpringBoot Vue MySQL这套组合之所以常年霸榜课设和中小企业内部项目是因为它踩中了几个非常实在的点。2.1 前后端分离为什么是当下的主流如果是五年前SpringBoot直接返回Thymeleaf模板页面也行但现在的同学出去实习就业大部分团队已经全面转向前后端分离。前端Vue负责页面渲染和交互后端SpringBoot只提供JSON接口两边通过RESTful API通信。这套模式的好处是前端可以单独部署调试后端接口可以给小程序、App等多端复用招聘市场上对这套组合的认可度也高。对于学习来说前后端分离还能帮助你理清职责边界——前端只管拿到数据、展示数据、收集用户输入后端只管校验参数、处理业务逻辑、读写数据库。很多同学代码写得乱根本原因就是前后端逻辑混在一起数据库查询条件散落在页面代码里。项目一开始就按分离架构组织这个好习惯会受益很久。2.2 SpringBoot在课程设计和毕业设计中的优势SpringBoot选型最直接的理由是零配置起步。传统的SSM框架要写一堆XML配置文件光环境搭建就能劝退一大半人。SpringBoot内嵌Tomcat一个main方法就能启动配合Spring Data JPA或MyBatis-Plus数据库操作也不需要手写大量样板代码。对于设备管理系统这种典型的管理类应用业务逻辑集中在增删改查和状态流转上SpringBoot的单体架构完全够用还不需要为了用微服务而用微服务。更重要的是SpringBoot的资料极其丰富遇到问题搜一下基本都能解决——这在赶进度的课设阶段是巨大的隐性优势。2.3 MySQL选型与版本注意点MySQL是这个项目最稳妥的数据库选择开箱即用、社区工具生态成熟。值得提醒的是安装版本建议选5.7或8.0如果选8.0要注意驱动名称从com.mysql.jdbc.Driver变成了com.mysql.cj.jdbc.Driver时区参数也要显式指定serverTimezoneAsia/Shanghai否则连接时会报时区错误。另一个选型建议是数据库字符集统一设置为utf8mb4别用utf8。设备名称里难免有生僻字或特殊符号utf8mb4才是完整的Unicode实现这也是很多人在做导入导出功能时发现乱码的根本原因。3. 系统功能模块梳理从设备台账到故障闭环开始写代码之前先把功能模块画清楚。这套系统我建议划分成六个核心模块基本覆盖中小企业设备管理的所有高频场景。3.1 设备台账管理设备台账是全部业务的数据源头。列表页需要支持多条件组合筛选设备编码模糊搜索、设备类型下拉选择、使用部门筛选、当前状态筛选。每条设备记录的核心字段包括字段说明设备编码系统自动生成或按规则手工录入全局唯一设备名称/型号自然语言描述便于检索设备类型关联分类表支持树形结构所属部门/责任人明确归属考核有依据购入日期/金额用于资产折旧统计需要选型当前状态正常运行、待维修、维修中、已报废这里特别建议把当前状态做成系统的核心状态机后面所有模块都会引用它。3.2 设备保养计划保养模块不是简单记录我保养了,而是要能定义保养周期规则。比如某台空压机每运转500小时保养一次或者某条生产线每个季度的第一个周一做检查。系统根据上次保养日期和周期自动计算出下次保养日期在仪表盘上展示未来两周内到期的保养任务。实现时我建议单独建保养计划表和保养执行记录表计划表定义未来应该做什么执行表记录实际做了什么两个表通过设备编码和计划编号关联。这样既有前瞻性又有追溯性。3.3 巡检管理巡检更偏现场执行层。普通员工扫码或手动登记巡检结果记录内容包括设备运行是否正常、有无异常噪音、关键仪表读数、现场照片等。巡检记录表至少需要巡检人、巡检时间、设备编码、正常/异常状态、问题描述、建议处理方式。这里有一个实用设计巡检发现异常时系统自动生成一条报修工单草稿避免用户二次填写。这个联动逻辑在答辩时非常加分因为它体现了系统不是孤立的表单集合而是一个有状态联动的业务系统。3.4 报修与维修闭环报修模块是整个系统里逻辑最复杂、也最能体现工程设计能力的地方。一个完整的报修流程应该是报修人提交报修申请填写设备、故障现象、紧急程度维修班组接到工单进行派单或抢单维修人执行维修填写处理方式、更换配件、维修工时报修人确认维修结果工单闭环所有工单进入历史记录支持按设备、按时间段统计工单表必须有状态字段常见的取值有待派单已提交、维修中已接单、待验收已提交维修结果、已完成报修人确认、已撤销。3.5 备件管理备件管理很容易被忽略但维修模块一旦涉及更换配件就必须有库存数据支撑。备件表记录备件编码、名称、规格、安全库存量、当前库存量。维修工单里填写使用了哪个备件、用了几件系统就自动扣减库存低于安全库存时在仪表盘给出补货提醒。这样设计的价值在于维修工单不再只是描述故障填个结论而是和库存系统打通形成业务闭环。这比单独做一个备件CRUD高级得多。3.6 统计报表报表模块是让管理层愿意用这套系统的关键。建议提供四个核心图表设备状态分布饼图每月维修工单数量趋势折线图按部门/设备类型的故障率排行维修费用和备件消耗统计技术实现上这类统计不需要实时聚合每天凌晨或每次工单流转时更新汇总数据即可避免大表做复杂JOIN导致页面卡顿。后端提供聚合接口返回统计结果前端用ECharts绘制图表就行。3.7 角色与权限三类角色怎么划分权限模型建议采用最通用的RBAC。至少设置三类角色管理员全部权限包括用户管理、参数配置、数据导出设备管理员设备台账、保养计划、备件管理的读写权限普通用户只看设备信息可发起维修工单对自己的工单有查看权限权限粒度到按钮级会更专业前端用自定义指令控制按钮显隐后端用拦截器校验接口权限两层都做才能防止绕过前端直接调用接口的越权操作。4. 数据库设计八张核心表如何撑起整个业务数据库设计是这套系统里最不能节省时间的部分表关系设计好后面写业务逻辑会非常顺畅。我直接给出一套经过实战打磨的落地方案。4.1 核心表清单与关系表名用途关键外键sys_user用户表角色IDsys_role角色表—device_type设备类型表父类型ID树形device设备台账表类型ID、部门IDmaintenance_plan保养计划表设备IDrepair_order维修工单表设备ID、操作人IDinspection_record巡检记录表设备IDspare_part备件表—再建三张关联表工单与备件的关联表repair_order_part、维修记录操作日志表operation_log、保养执行记录表maintenance_record。整套下来十二张表左右张张有业务含义不多不少。4.2 设备表设计要点设备表是核心主表字段设计上除了基础信息一定要考虑扩展性。比如增加custom_field_json列存放一些非结构化自定义属性——不同类别的设备需要记录的参数是不一样的专门为每类设备建不同的表不现实用JSON字段可以灵活兼容。设备状态字段建议用TINYINT存数字枚举别直接存中文避免排序、统计时遇到编码问题。代码里对应一个常量类或枚举类页面上展示时再做映射。CREATE TABLE device ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, device_code VARCHAR(50) NOT NULL COMMENT 设备编码, device_name VARCHAR(100) NOT NULL COMMENT 设备名称, device_type_id BIGINT NOT NULL COMMENT 设备类型ID, model VARCHAR(100) DEFAULT NULL COMMENT 规格型号, department VARCHAR(100) DEFAULT NULL COMMENT 所属部门, manager VARCHAR(50) DEFAULT NULL COMMENT 负责人, purchase_date DATE DEFAULT NULL COMMENT 购入日期, purchase_price DECIMAL(10,2) DEFAULT NULL COMMENT 购入金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态: 0正常 1待维修 2维修中 3已报废, custom_field_json TEXT COMMENT 自定义扩展字段, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_device_code (device_code), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT 设备台账表;4.3 维修工单表状态机怎么落到数据库里维修工单表要能支撑完整的流程闭环状态流转是核心逻辑。字段上除了设备ID、故障描述、紧急程度还要有报修人ID、当前处理人ID、接单时间、完成时间、维修方案、验收结果。实际开发中状态机最容易犯的错是只在前端控制按钮和状态后端接口没有校验状态合法性。比如一个已经已完成的工单再次提交维修结果会导致时间线混乱。正确的做法是在Service层写状态流转方法每个方法开头先检查当前状态和期望状态是否匹配不匹配直接抛业务异常。orders表设计时再强调两点处理人字段存用户表ID而不是姓名这样可以避免重名问题需要显示姓名时再关联查询时间字段统一用DATETIME别用VARCHAR存字符串时间否则后续统计排序会出大麻烦。4.4 保养计划与执行记录两张表怎么做联动计划表定义计划执行表记录实际执行。计划表字段包括设备ID、保养周期类型按天数或按运行时长、周期值、上次执行时间、系统计算的下次执行时间、当前启用状态。当系统判定某个计划已到期需要生成保养待办提醒。考虑到中小企业不一定有完善的定时任务基础设施最简单的方案是不用定时器而是在用户登录后的仪表盘接口里实时查询下次执行时间 当前日期且未关闭的计划然后展示成待办。这种懒查询方案在数据量不大的场景下完全够用还省去了定时任务的心跳维护。5. 后端骨架实现从登录鉴权到报修流程的状态机后端这部分我挑四个最核心的骨架讲清楚它们是整套系统的技术底座。5.1 JWT 拦截器实现登录态设备管理系统不需要引入复杂的Spring Security因为它只是内部管理系统用JWT做无状态认证足够。设计思路用户登录成功后后端签发一个有效期两小时的JWT包含用户ID、用户名、角色编码前端把Token存到localStorage每次请求在HTTP头里带Authorization: Bearer {token}后端拦截器校验Token有效性解析出用户信息放到请求上下文里Token校验逻辑要特别注意Token过期时的处理不要只返回笼统的未认证建议返回明确业务码AUTH_EXPIRED前端收到后统一跳转登录页。5.2 统一返回结构与全局异常处理所有接口统一返回固定格式{ code: 200, message: success, data: {} }这个格式配合全局异常管理器能让Controller层代码非常干净业务逻辑里只需要把真实数据往Result里一放就行不用每个接口都写try-catch。业务异常的抛出方式建议定义自定义异常类BizException在Service里遇到设备状态不允许维修这类业务冲突时直接抛出由全局处理器统一包装成JSON返回。这样做的好处是Controller层不会因为异常处理代码而变得臃肿排查问题时日志里也能看到明确的业务错误码。5.3 设备报修流程的Service实现要点维修工单的Service是整套系统里最有含金量的代码段。我贴一下核心的状态流转片段Service public class RepairOrderServiceImpl implements RepairOrderService { Override Transactional(rollbackFor Exception.class) public void acceptOrder(Long orderId, Long operatorId) { RepairOrder order repairOrderRepository.findById(orderId) .orElseThrow(() - new BizException(工单不存在)); // 核心状态机校验 if (!OrderStatus.PENDING_DISPATCH.equals(order.getStatus())) { throw new BizException(当前工单状态不允许接单); } order.setStatus(OrderStatus.REPAIRING.getCode()); order.setHandlerId(operatorId); order.setAcceptTime(LocalDateTime.now()); // 同时联动设备状态让设备进入维修中 Device device deviceRepository.findById(order.getDeviceId()).orElseThrow(); device.setStatus(DeviceStatus.REPAIRING.getCode()); deviceRepository.save(device); repairOrderRepository.save(order); // 操作日志 operationLogService.record(工单接单, orderId, operatorId, 工单 order.getOrderNo() 被接单设备进入维修中状态); } }这段代码里有两个要点一是Transactional必须加上工单状态更新和设备状态更新要保证原子性事务里谁失败就一起回滚二是操作日志要配合写入这是管理系统的审计需求也是答辩时能说的亮点。5.4 MyBatis-Plus还是Spring Data JPA这两个ORM我实际都用过各有各的顺手之处。我的建议是如果更熟悉SQL或者需要频繁做多表复杂统计查询选MyBatis-Plus分页插件和代码生成器都很省事如果希望实体层更干净关联关系依赖框架自动处理选Spring Data JPA但要注意一点不管选哪个复杂统计报表不要用ORM去硬拼建议直接写原生SQL或使用MyBatis-Plus的selectMaps返回Map结构再在Service层组装成前端需要的格式。ORM能帮的是对象之间的增删改查聚合分析永远是SQL的主场。6. 前端工程化实践Vue3 Element Plus 的页面组织方式前端部分我默认使用的是Vue3 Vite Element Plus的组合。Vue2虽然还有存量项目但新启动的课设项目我强烈建议直接上Vue3生态已经完全成熟。6.1 项目脚手架与目录结构用Vite创建Vue3项目就行比Webpack构建快不少npm create vitelatest device-web -- --template vue推荐的目录组织方式src/ api/ // 按模块拆分的接口请求 router/ // 路由配置 store/ // Pinia状态管理存用户信息和权限 views/ // 页面组件 components/ // 全局复用组件 utils/ // axios实例、公共工具函数目录清晰的好处是答辩或者后续接手的人不用到处找代码这也是专业工程团队的基本要求哪怕课设也应该按这个规范来。6.2 路由与权限控制路由配置里把需要登录才能访问的页面统一放在一个嵌套路由下套一个Layout组件。前端权限控制做两层第一层是路由守卫检查本地Token是否存在没有就跳登录页router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.public) { next() } else if (token) { next() } else { next(/login) } })第二层是按钮级权限封装一个v-permission自定义指令根据用户角色判断按钮是否渲染。不要以为前端做了权限就万事大吉后端接口必须也做权限校验。前端控制只是用户体验层面的优化真正的数据安全都在后端拦截器里。6.3 axios封装与跨域处理axios实例统一封装核心配置包括请求拦截器里附加Token、响应拦截器里统一解析后端返回格式遇到code ! 200时用Message组件提示错误信息遇到401跳转登录页。开发环境跨域最简单的方案是在Vite的server.proxy配置里做代理server: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样做的好处是前端请求直接写/api/xxx开发时Vite自动转发到后端服务生产环境再把后端接口路径配成同域即可不需要后端做CORS跨域配置干净利落。6.4 核心页面设备列表与维修工单怎么设计交互设备列表页是整个系统的门面。建议用Element Plus的el-table展示数据配合顶部的筛选表单和分页组件。这里分享一个优化细节大数据量下列表加载慢后端接口一定要分页前端翻页时通过URL参数保存当前页码和筛选条件用户编辑完一条记录返回列表还能停留在刚才的位置这个小细节在实际使用中很受欢迎。维修工单页面的交互设计核心是状态驱动操作根据工单状态动态渲染可执行的操作按钮。待派单状态显示接单按钮、维修中显示提交维修结果按钮、待验收状态显示验收通过/驳回按钮。这种交互方式不会让用户面对一堆无意义的按钮业务逻辑也一目了然。7. 跑通项目的关键细节与毕设答辩避坑指南最后这部分是干货中的干货全都是我在实际部署和帮同学调试项目过程中遇到过的典型问题。7.1 版本兼容问题汇总我把常见的版本坑整理成一张表照着检查能省半天时间组件推荐版本常见坑JDK8或11别一上来用21的测试版部分框架可能不兼容Spring Boot2.7.x或3.x3.x要求JDK17注意对应关系MySQL5.7或8.08.0驱动类名变更时区参数必须设置Node.js18部分Vite版本对低版本Node不友好Vue3.4保持npm包版本一致别混装Vue2和Vue3组件7.2 前后端联调的常见报错后端起了服务前端页面上却拿不到数据这类问题占我平时答疑的一半。最容易犯的三个错前端请求路径和Controller的RequestMapping不一致多了一个前缀或少了一个/数据格式对不上后端返回的是一个Date对象前端直接渲染成莫名其妙的时间字符串需要手动格式化跨域配置缺失或者Nginx反向代理配置有误导致请求发出去后浏览器报CORS错误排查技巧先开浏览器F12看Network面板确认请求状态码和响应内容再从后端日志看有没有请求进来这样能快速定位问题出在前端还是后端。7.3 答辩/课设验收的重点准备如果这个项目是用于毕业设计或课程设计答辩时要展示的深度和侧重点和实际交付不太一样。面试官和评审老师通常会关注三个层次的问题第一层是这个小项目你都做了哪些功能——这个只需要把功能模块演示一遍就行。第二层是你为什么要这样设计——比如为什么选MySQL不选Oracle、为什么设备状态要单独维护、为什么工单要分状态流转这些必须要有清晰的业务理由。第三层是遇到某个具体问题你怎么解决的这时候最加分的就是讲真实的调试经历比如当时你查了一个下午终于发现是参数类型不符这类细节最能证明项目是你自己亲手写出来的。7.4 从课设到真正可用的差距说实话大部分课设级项目距离企业内部真正投入使用还有一段距离主要是缺这几个能力多租户支持多个分公司数据隔离、消息通知工单流转时微信或短信提醒、文件上传巡检照片和维修报告附件、在线导出报表Excel导出功能。但这些差距恰恰是你可以继续扩展的方向。如果答辩时能主动说下一步我计划在工单流转时引入消息提醒机制评审的印象分会明显不一样。我自己在练习这个项目时还有一个体会不要为了追求功能的多少而忽略流程的闭环。一个从报修到维修到验收全程可追踪的工单流程比十个只做了增删改查却互不关联的功能都更有价值。把业务讲透、把状态流转做严谨这套系统的含金量就达到了。