做毕业设计选题的时候很多人一听“大学体育器材管理系统”就觉得太普通好像谁都能做。但真正上手之后我才发现这个题目被低估了——它恰好覆盖了信息管理类系统最核心的完整闭环器材录入、借用归还、损坏报修、库存盘点、统计报表每一步都要求你认真设计流程和数据结构。我这次用SpringBoot和Vue.js完整做下来前后花了三个多月期间把后端接口设计、前端组件组织、权限控制、部署上线这些环节都踩了一遍。这篇文章就完整复盘整个过程把题目拆解、技术选型、核心代码、常见坑全部写清楚。如果你是正在考虑这个题目的在校生或者是想找一个中小型管理系统练手的开发者这篇内容可以直接照着走。它不是那种空谈理论的教程而是我实际跑完整个项目之后沉淀下来的实操记录。1. 项目概述这套系统到底在解决什么问题1.1 高校体育器材管理的现状痛点先说实话我一开始以为体育器材管理就是个“登记表”问题结果去学校器材室蹲了半天才发现真实场景远没那么简单。很多高校的器材室到现在还是Excel表格加纸质登记本。学生借一颗篮球管理员要在本子上手写学号、姓名、联系方式、借出时间归还时再勾一笔。遇到上课高峰时段十几个人排队登记管理员根本没时间核对器材状态更别提什么磨损程度、定期盘点、到期归还提醒了。我亲眼看到有人借走羽毛球拍后两周没还管理员翻登记本翻了半天才找到联系方式。器材本身也有特殊性。体育器材和图书不一样球类会有磨损、气不足、破裂健身器械存在安全隐患跨校区调拨、大批量采购、报废处置这些线下流程全靠人工记录账实对不上是常态。这些痛点整合起来就是一套管理系统的需求点器材档案数字化、借用流程规范化、归还和报修自动化、数据报表可视化。1.2 题目拆解从技术选型到实现路径这个题目在网上的常见叫法有三个版本偏向“毕业设计”的写法偏向宣传介绍的写法还有强调“全生命周期数字化”的写法。但不管叫什么核心内容是一致的——后端用SpringBoot做业务逻辑和数据访问前端用Vue.js做交互界面再加上MySQL存数据。我在最开始也犹豫过要不要用“微服务架构”。标题里写着是基于微服务的校园运动装备系统但我评估下来发现毕设场景下强行拆微服务反而会给自己挖坑。真正合理的做法是先用模块化单体的方式把后端代码组织清晰保证每个业务模块之间低耦合这比硬拆多个服务实用得多。具体原因后面专门用一节来说。2. 系统整体设计与模块拆解2.1 功能模块原型规划我先画了一张完整的思维导图把整个系统拆成前台和后台两个视角然后才动手写代码。功能模块不要一开始就贪多先把刚需做扎实再考虑锦上添花。模块面向角色核心功能登录认证所有用户账号密码登录、Token鉴权、密码加密器材管理管理员器材录入、修改、删除、状态变更、类别维护借用管理学生、管理员在线借用、续借、归还、借用记录查询报修管理学生、管理员器材报修提交、维修进度、报废审核用户管理管理员学生信息维护、账号启停、角色分配数据看板管理员器材库存统计、借用排行、逾期未还列表学生在手机或电脑上登录后能看到当前可借用的器材列表和库存数量提交借用申请后在约定时间内去器材室领取管理员在后台审核、登记实际出库这样线上预约和线下领取就对齐了。我这里特别提一下统计看板。很多同学容易忽略这个模块觉得不就是几个图表嘛。但答辩时老师几乎一定会问“你这个系统有没有数据分析”把器材分类占比、借用频率Top10、逾期率按周展示出来这个系统的完整度和亮点都提上来了。2.2 核心流程设计借、还、修、盘一个器材从采购入库到报废出库会经历多种状态我用状态机把整个流程理清楚。器材的状态包括在库、已借出、维修中、已报废。所有状态变更都要产生一条记录这就是“全生命周期”的意思。拿借用来说完整流程是这样的学生提交借用申请时系统先判断该器材是否存在且状态为“在库”然后才能生成借用记录领取器材时管理员确认出库器材状态变为“已借出”。归还流程则是反过来管理员检查器材完好后点击归还器材状态恢复“在库”如果检查时发现损坏直接转成“维修中”并生成报修单。这里有一个容易被忽视的设计归还时必须校验借用记录是否存在且状态正确防止有人先归还再借出造成状态错乱。我用的方式是给每条借用记录维护一个status字段借出时从“待领取”变“已借出”归还时从“已借出”变“已归还”。2.3 角色权限与数据隔离用户角色分为学生、器材管理员、系统管理员三种。对于毕设来说不需要引入太重的权限框架用简单的RBAC基于角色的访问控制就够了。我不建议在用户表里直接加一个“角色”字段了事虽然那样最简单但后续如果要增加“协管员”之类的角色改动会很大。更好的做法是建用户表、角色表、用户角色关联表三张表登录后把当前用户的所有角色查出来放进登录态后端接口再用注解或拦截器做权限判断。前后端权限要配合来做前端根据角色控制菜单显示、按钮点击提升体验后端在接口层面做二次校验保证绕过前端也能被拦住。记住一句话前端控制是体验层面的后端校验才是安全层面的。3. SpringBoot后端实现要点3.1 数据库设计与持久层技术选型数据库我设计了6张核心表用户表、角色表、用户角色关联表、器材分类表、器材表、借用记录表。另外还加了报修记录表和操作日志表总共8张。器材表里除了基础字段名称、分类、品牌、单价、购置日期我特意加了三个字段库存总数、可借数量、状态。库存总数用于展示总量可借数量用于判断能否借出状态则标识“在库/已借出/维修中”中的一个。这三个字段看似冗余但查询时非常方便不用每次实时统计所有借用记录。持久层框架方面毕业设计最常用的就是Spring Data JPA和MyBatis-Plus两个选择。我个人更推荐JPA因为实体关系映射写起来很直观一对多、多对多关系通过注解就能体现对展示代码逻辑和答辩都有帮助。如果你对SQL更熟悉用MyBatis-Plus也可以它提供的LambdaQueryWrapper做条件查询确实简洁。Entity Table(name equipment) public class Equipment { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private String name; private String model; private Integer totalCount; private Integer availableCount; Enumerated(EnumType.STRING) private EquipmentStatus status; }提一个细节库存扣减不要用先查再更新这种两步操作。比如两个学生同一秒提交借用各自都查到当前可借数量是1然后都往“可借数量−1”的方向走就会出现超借。我在Mapper层写了一个带条件的更新语句只有当前值满足条件时才做更新或者使用数据库的悲观锁/乐观锁来解决这个问题。毕设如果能把并发控制写出来绝对是个加分项。3.2 器材借用的核心业务库存锁定与归还超时后端的业务逻辑不能只是简单的增删改查一定要把“规则”写出来否则跟一张Excel表没本质区别。我在借还模块里加了这样几条规则每个学生同时最多只能借2件器材防止一个人把球都借走。借期默认7天到期前1天可以续借续借只能1次。逾期未还会在管理员后台的“逾期列表”中醒目展示。归还时如果设备状态异常不能直接归还必须先走报修流程。代码实现上借用接口最关键的是事务控制。借用操作包含三步检查可借数量→创建借用记录→扣减可借数量。只要其中任何一步失败都应该回滚。在SpringBoot里给方法加上Transactional注解就能实现声明式事务。另一个踩坑点是归还超时提醒。有人误以为要去写定时任务其实最简单的方案是管理员后台查询时对“借出时间 7天 当前时间”的记录做一个expired标记字段查询SQL里判断即可。真正需要定时任务时再加Scheduled注解每天凌晨跑一次把逾期记录批量标记并给相关用户生成提醒通知。3.3 统一返回体、全局异常与登录鉴权前后端分离开发时接口返回结构必须统一不然前端写判断逻辑会炸裂。我定义了一个ResultT对象包含code、message、data三部分成功时code为200业务失败时code为具体的业务错误码。public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } }全局异常处理也是必做的。SpringBoot里的RestControllerAdvice配合ExceptionHandler可以把空指针、参数校验失败、重复提交等异常统一拦下来返回统一的错误JSON而不是给前端一个堆栈信息页面。这样不但上线时排错方便答辩演示时也显得项目很规范。登录鉴权我用的是JWT。用户登录成功后生成一个带过期时间的token后续请求在Header里带上这个token后端写一个拦截器解析并校验。需要注意的是密码存储一定要用BCrypt加密千万不要明文入库这是最基本的职业素养。4. Vue.js前端实现与接口联调4.1 前端脚手架与目录组织前端我用Vue CLI创建项目后来也尝试过Vite速度确实快不少但Vue CLI生态更稳用哪个都行不影响最终效果。目录结构千万别随便建我踩过一锅粥式的开发方式组件乱放接口文件散落各处改一个功能要找半天。后来整理成这种标准结构src/ ├── api/ // 所有后端接口请求统一放这里 ├── assets/ // 静态资源 ├── components/ // 公共组件 ├── router/ // 路由配置 ├── store/ // 状态管理 ├── views/ // 页面组件 └── utils/ // 工具类比如request.js封装axiosutils/request.js是对axios的二次封装统一设置baseURL、拦截请求自动加token、拦截响应统一处理错误码。这样每个页面里只需要调用api/equipment.js里的函数代码非常清爽。开发阶段还有个关键配置——代理。前后端分离开发时后端跑在8080端口前端跑在8081端口直接请求接口必然跨域。我在vue.config.js里配置了devServer代理把/api前缀的请求全部转发到后端服务开发时完全感受不到跨域的存在线上再通过Nginx配置反向代理即可。4.2 状态管理Vuex还是Pinia本项目状态管理的核心需求是保存登录用户信息、保存角度常量、保存全局购物车式的临选。以前我习惯用Vuex现在更推荐PiniaAPI更简洁不像Vuex那样需要写一堆mutations才能改状态。最实用的处理是用户登录成功后把用户基本信息和角色信息通过store保存同时同步写入localStorage。因为刷新页面时store里的数据会丢失从localStorage重新读取是常规操作。但要注意前端只负责展示用户信息是否真正有权限必须由后端接口说了算本地篡改角色是无效的。路由守卫也是一定要写的。router.beforeEach里判断有没有token没有就跳到登录页有token但当前路由要求管理员权限就看用户角色里有没有管理员没有就提示无权访问。这个逻辑其实不复杂但能让整个系统的完整度高一大截。4.3 前后端联调中的常见错位前后端分离开发最花时间的不是写接口而是对齐预期。我整理了自己联调时出过问题的几类情况给后来人避雷问题类型具体表现解决方案时间格式后端返回2025-06-10T15:30:00前端想显示2025-06-10后端加JsonFormat指定格式或前端用dayjs处理字段命名后端availableCount前端写available_count统一约定驼峰命名或后端用JsonProperty映射状态码语义后端业务失败也返回200前端无法判断统一Result结构前端的响应拦截器统一判断code空值问题列表项某字段为null前端直接渲染报错前端用可选链?.或提供默认值这些都不算难但第一次做前后端分离的人大概率会在这里卡住。我的建议是前后端各自开发时先约定好接口文档哪怕只用文档记录字段名和枚举值也能少返工一半。5. 关于微服务架构的取舍毕业设计要不要上微服务5.1 伪分布式 vs 单体模块化标题里提到的微服务架构我在这里可以老老实实告诉你我最终的选择没有为这个项目真正部署多个服务节点而是采用了模块化单体的架构同时预留了拆分微服务的可能性。为什么因为微服务是为了解决大型系统的特定问题而存在的团队各自独立部署、模块独立扩展、故障隔离。而一个器材管理系统的真实并发量单体应用完全能扛得住。硬把用户模块、器材模块、借用模块拆成三个SpringBoot服务加上注册中心、网关、服务间调用每个服务都要处理数据库连接和配置工作量直接翻几倍这就是所谓的“伪分布式”——看起来用了很多技术实际上每个服务都只是个空壳。用生活类比来说你在学校门口开一个水果摊不需要建一套冷链物流网络和多个仓储基地那是给全国连锁超市用的。先把手里的生意做成精品小店比堆砌一套用不上的大系统更有效。5.2 什么时候真的需要微服务我也会给老师一个合理的解释如果这个系统要部署在多个校区每个校区独立管理自己的器材库同时需要统一对外提供服务这时候按校区或按业务域拆成服务才是有意义的。微服务真正解决的是独立伸缩和独立部署的问题。比如借用系统的并发是器材管理系统的十倍只有微服务才能单独把借用模块扩容单体应用一扩容所有模块一起占资源。但在毕业设计演示场景里这些优势根本看不出来还增加了系统复杂度。5.3 不拆微服务也能做的亮点既然不硬上微服务怎么让项目有亮点我的做法是在单体架构内把代码拆成清晰的业务分层同时引入中间件增加技术含量Redis做缓存热点器材的库存数据放到缓存里降低数据库压力。定时任务每天凌晨自动扫描逾期未还的记录给相关用户生成通知。操作日志AOP用Aspect切面统一记录关键接口的操作行为做到“每一步修改都有痕迹”。Docker部署写一个docker-compose.yml把MySQL、Redis、后端、前端一键部署起来。这几个点每个都推进到位生成的系统从工程化角度看已经超过大部分毕业设计了。你甚至可以在答辩时说清楚“为什么这个规模不需要微服务”这本身就是对架构理解的体现比背概念拿的分还高。6. 部署与常见问题排查实录6.1 本地联调到打包部署本地开发完成后进入打包部署环节。后端在项目根目录执行mvn clean package生成一个可执行的Jar包前端执行npm run build生成dist静态文件目录。把前端打包进后端有两种方式一种是直接把dist里的文件复制到SpringBoot的src/main/resources/static目录再重新打包Jar另一种是前后端分别部署后端提供接口前端用Nginx托管静态文件。毕设答辩展示的时候我更推荐第二种更符合前后端分离的真实生产模式。但如果你是演示环境有限也可以选择第一种“塞进Jar”的办法一个Jar就能跑起来省去配置Nginx的麻烦。6.2 把前端打包放进SpringBoot的坑前端打包放进SpringBoot的static目录后存在一个经典问题刷新页面404。原因很简单Vue是单页面应用路由切换实际是在前端完成的后端没有对应路径。当你访问http://localhost:8080/equipment/list并刷新时SpringBoot会尝试找这个URL对应的Controller找不到就返回404。解决方案有两个一是前端路由使用hash模式URL里会有#/equipment/list刷新时不会请求后端路径二是在后端配置一个路由转发把非API的路径全部转发到index.html。毕设阶段用hash模式最省事改动一行代码就好。6.3 高频问题速查表我把自己实际踩过的坑整理成一张速查表几乎覆盖了从零搭建到上线会遇到的大部分问题问题原因解决办法前端接口全部404代理配置没生效或线上Nginx没配/api转发检查vue.config.js代理线上检查Nginx配置登录成功后刷新又跳登录用户信息只存在内存中刷新丢失使用localStorage持久化用户信息器材库存变成负数并发借出没有做库存校验或锁使用原子更新或乐观锁实现库存扣减JWT过期后接口报401前端没有统一处理token失效在axios响应拦截器里捕获401并跳转登录页数据库连接出现时区报错MySQL连接串没配置时区JDBC URL加上serverTimezoneAsia/Shanghai接口返回的日期格式串少8小时后端时区与数据库时区不一致统一配置spring.jackson.time-zoneGMT8前端打包后图标不显示静态资源路径使用了绝对路径设置Vue的publicPath为相对路径./6.4 定时任务里最容易忽视的一个小问题如果你用Scheduled做每日逾期扫描要特别注意默认情况下Spring的定时任务是单线程执行的。如果你写了两个定时任务第一个任务没跑完第二个任务会排队等待不管它们的执行时间是不是重叠的。代码实现上把定时任务单独放到一个配置类里并且给线程池加个Bean定义TaskScheduler配置线程数大于1。这个细节虽然小但能让你在答辩演示时避免“定时任务好像不执行”的尴尬。最后再分享一个小技巧也是我整个项目中受益最大的一点别急着写代码先用流程图把器材的每一个状态转换画清楚。借出、归还、报修、报废这些状态之间的转移关系一旦理清后面的数据库设计、接口设计、前端页面设计就全部顺下来了。我整个项目推进最顺利的部分恰恰是最早花了两天画流程图的那一版设计。 
长河君 · 2026/10/8 2:31:42 · 阅读 1.2k SpringBoot+Vue高校体育器材管理系统从零到上线全记录
做毕业设计选题的时候很多人一听“大学体育器材管理系统”就觉得太普通好像谁都能做。但真正上手之后我才发现这个题目被低估了——它恰好覆盖了信息管理类系统最核心的完整闭环器材录入、借用归还、损坏报修、库存盘点、统计报表每一步都要求你认真设计流程和数据结构。我这次用SpringBoot和Vue.js完整做下来前后花了三个多月期间把后端接口设计、前端组件组织、权限控制、部署上线这些环节都踩了一遍。这篇文章就完整复盘整个过程把题目拆解、技术选型、核心代码、常见坑全部写清楚。如果你是正在考虑这个题目的在校生或者是想找一个中小型管理系统练手的开发者这篇内容可以直接照着走。它不是那种空谈理论的教程而是我实际跑完整个项目之后沉淀下来的实操记录。1. 项目概述这套系统到底在解决什么问题1.1 高校体育器材管理的现状痛点先说实话我一开始以为体育器材管理就是个“登记表”问题结果去学校器材室蹲了半天才发现真实场景远没那么简单。很多高校的器材室到现在还是Excel表格加纸质登记本。学生借一颗篮球管理员要在本子上手写学号、姓名、联系方式、借出时间归还时再勾一笔。遇到上课高峰时段十几个人排队登记管理员根本没时间核对器材状态更别提什么磨损程度、定期盘点、到期归还提醒了。我亲眼看到有人借走羽毛球拍后两周没还管理员翻登记本翻了半天才找到联系方式。器材本身也有特殊性。体育器材和图书不一样球类会有磨损、气不足、破裂健身器械存在安全隐患跨校区调拨、大批量采购、报废处置这些线下流程全靠人工记录账实对不上是常态。这些痛点整合起来就是一套管理系统的需求点器材档案数字化、借用流程规范化、归还和报修自动化、数据报表可视化。1.2 题目拆解从技术选型到实现路径这个题目在网上的常见叫法有三个版本偏向“毕业设计”的写法偏向宣传介绍的写法还有强调“全生命周期数字化”的写法。但不管叫什么核心内容是一致的——后端用SpringBoot做业务逻辑和数据访问前端用Vue.js做交互界面再加上MySQL存数据。我在最开始也犹豫过要不要用“微服务架构”。标题里写着是基于微服务的校园运动装备系统但我评估下来发现毕设场景下强行拆微服务反而会给自己挖坑。真正合理的做法是先用模块化单体的方式把后端代码组织清晰保证每个业务模块之间低耦合这比硬拆多个服务实用得多。具体原因后面专门用一节来说。2. 系统整体设计与模块拆解2.1 功能模块原型规划我先画了一张完整的思维导图把整个系统拆成前台和后台两个视角然后才动手写代码。功能模块不要一开始就贪多先把刚需做扎实再考虑锦上添花。模块面向角色核心功能登录认证所有用户账号密码登录、Token鉴权、密码加密器材管理管理员器材录入、修改、删除、状态变更、类别维护借用管理学生、管理员在线借用、续借、归还、借用记录查询报修管理学生、管理员器材报修提交、维修进度、报废审核用户管理管理员学生信息维护、账号启停、角色分配数据看板管理员器材库存统计、借用排行、逾期未还列表学生在手机或电脑上登录后能看到当前可借用的器材列表和库存数量提交借用申请后在约定时间内去器材室领取管理员在后台审核、登记实际出库这样线上预约和线下领取就对齐了。我这里特别提一下统计看板。很多同学容易忽略这个模块觉得不就是几个图表嘛。但答辩时老师几乎一定会问“你这个系统有没有数据分析”把器材分类占比、借用频率Top10、逾期率按周展示出来这个系统的完整度和亮点都提上来了。2.2 核心流程设计借、还、修、盘一个器材从采购入库到报废出库会经历多种状态我用状态机把整个流程理清楚。器材的状态包括在库、已借出、维修中、已报废。所有状态变更都要产生一条记录这就是“全生命周期”的意思。拿借用来说完整流程是这样的学生提交借用申请时系统先判断该器材是否存在且状态为“在库”然后才能生成借用记录领取器材时管理员确认出库器材状态变为“已借出”。归还流程则是反过来管理员检查器材完好后点击归还器材状态恢复“在库”如果检查时发现损坏直接转成“维修中”并生成报修单。这里有一个容易被忽视的设计归还时必须校验借用记录是否存在且状态正确防止有人先归还再借出造成状态错乱。我用的方式是给每条借用记录维护一个status字段借出时从“待领取”变“已借出”归还时从“已借出”变“已归还”。2.3 角色权限与数据隔离用户角色分为学生、器材管理员、系统管理员三种。对于毕设来说不需要引入太重的权限框架用简单的RBAC基于角色的访问控制就够了。我不建议在用户表里直接加一个“角色”字段了事虽然那样最简单但后续如果要增加“协管员”之类的角色改动会很大。更好的做法是建用户表、角色表、用户角色关联表三张表登录后把当前用户的所有角色查出来放进登录态后端接口再用注解或拦截器做权限判断。前后端权限要配合来做前端根据角色控制菜单显示、按钮点击提升体验后端在接口层面做二次校验保证绕过前端也能被拦住。记住一句话前端控制是体验层面的后端校验才是安全层面的。3. SpringBoot后端实现要点3.1 数据库设计与持久层技术选型数据库我设计了6张核心表用户表、角色表、用户角色关联表、器材分类表、器材表、借用记录表。另外还加了报修记录表和操作日志表总共8张。器材表里除了基础字段名称、分类、品牌、单价、购置日期我特意加了三个字段库存总数、可借数量、状态。库存总数用于展示总量可借数量用于判断能否借出状态则标识“在库/已借出/维修中”中的一个。这三个字段看似冗余但查询时非常方便不用每次实时统计所有借用记录。持久层框架方面毕业设计最常用的就是Spring Data JPA和MyBatis-Plus两个选择。我个人更推荐JPA因为实体关系映射写起来很直观一对多、多对多关系通过注解就能体现对展示代码逻辑和答辩都有帮助。如果你对SQL更熟悉用MyBatis-Plus也可以它提供的LambdaQueryWrapper做条件查询确实简洁。Entity Table(name equipment) public class Equipment { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private String name; private String model; private Integer totalCount; private Integer availableCount; Enumerated(EnumType.STRING) private EquipmentStatus status; }提一个细节库存扣减不要用先查再更新这种两步操作。比如两个学生同一秒提交借用各自都查到当前可借数量是1然后都往“可借数量−1”的方向走就会出现超借。我在Mapper层写了一个带条件的更新语句只有当前值满足条件时才做更新或者使用数据库的悲观锁/乐观锁来解决这个问题。毕设如果能把并发控制写出来绝对是个加分项。3.2 器材借用的核心业务库存锁定与归还超时后端的业务逻辑不能只是简单的增删改查一定要把“规则”写出来否则跟一张Excel表没本质区别。我在借还模块里加了这样几条规则每个学生同时最多只能借2件器材防止一个人把球都借走。借期默认7天到期前1天可以续借续借只能1次。逾期未还会在管理员后台的“逾期列表”中醒目展示。归还时如果设备状态异常不能直接归还必须先走报修流程。代码实现上借用接口最关键的是事务控制。借用操作包含三步检查可借数量→创建借用记录→扣减可借数量。只要其中任何一步失败都应该回滚。在SpringBoot里给方法加上Transactional注解就能实现声明式事务。另一个踩坑点是归还超时提醒。有人误以为要去写定时任务其实最简单的方案是管理员后台查询时对“借出时间 7天 当前时间”的记录做一个expired标记字段查询SQL里判断即可。真正需要定时任务时再加Scheduled注解每天凌晨跑一次把逾期记录批量标记并给相关用户生成提醒通知。3.3 统一返回体、全局异常与登录鉴权前后端分离开发时接口返回结构必须统一不然前端写判断逻辑会炸裂。我定义了一个ResultT对象包含code、message、data三部分成功时code为200业务失败时code为具体的业务错误码。public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } }全局异常处理也是必做的。SpringBoot里的RestControllerAdvice配合ExceptionHandler可以把空指针、参数校验失败、重复提交等异常统一拦下来返回统一的错误JSON而不是给前端一个堆栈信息页面。这样不但上线时排错方便答辩演示时也显得项目很规范。登录鉴权我用的是JWT。用户登录成功后生成一个带过期时间的token后续请求在Header里带上这个token后端写一个拦截器解析并校验。需要注意的是密码存储一定要用BCrypt加密千万不要明文入库这是最基本的职业素养。4. Vue.js前端实现与接口联调4.1 前端脚手架与目录组织前端我用Vue CLI创建项目后来也尝试过Vite速度确实快不少但Vue CLI生态更稳用哪个都行不影响最终效果。目录结构千万别随便建我踩过一锅粥式的开发方式组件乱放接口文件散落各处改一个功能要找半天。后来整理成这种标准结构src/ ├── api/ // 所有后端接口请求统一放这里 ├── assets/ // 静态资源 ├── components/ // 公共组件 ├── router/ // 路由配置 ├── store/ // 状态管理 ├── views/ // 页面组件 └── utils/ // 工具类比如request.js封装axiosutils/request.js是对axios的二次封装统一设置baseURL、拦截请求自动加token、拦截响应统一处理错误码。这样每个页面里只需要调用api/equipment.js里的函数代码非常清爽。开发阶段还有个关键配置——代理。前后端分离开发时后端跑在8080端口前端跑在8081端口直接请求接口必然跨域。我在vue.config.js里配置了devServer代理把/api前缀的请求全部转发到后端服务开发时完全感受不到跨域的存在线上再通过Nginx配置反向代理即可。4.2 状态管理Vuex还是Pinia本项目状态管理的核心需求是保存登录用户信息、保存角度常量、保存全局购物车式的临选。以前我习惯用Vuex现在更推荐PiniaAPI更简洁不像Vuex那样需要写一堆mutations才能改状态。最实用的处理是用户登录成功后把用户基本信息和角色信息通过store保存同时同步写入localStorage。因为刷新页面时store里的数据会丢失从localStorage重新读取是常规操作。但要注意前端只负责展示用户信息是否真正有权限必须由后端接口说了算本地篡改角色是无效的。路由守卫也是一定要写的。router.beforeEach里判断有没有token没有就跳到登录页有token但当前路由要求管理员权限就看用户角色里有没有管理员没有就提示无权访问。这个逻辑其实不复杂但能让整个系统的完整度高一大截。4.3 前后端联调中的常见错位前后端分离开发最花时间的不是写接口而是对齐预期。我整理了自己联调时出过问题的几类情况给后来人避雷问题类型具体表现解决方案时间格式后端返回2025-06-10T15:30:00前端想显示2025-06-10后端加JsonFormat指定格式或前端用dayjs处理字段命名后端availableCount前端写available_count统一约定驼峰命名或后端用JsonProperty映射状态码语义后端业务失败也返回200前端无法判断统一Result结构前端的响应拦截器统一判断code空值问题列表项某字段为null前端直接渲染报错前端用可选链?.或提供默认值这些都不算难但第一次做前后端分离的人大概率会在这里卡住。我的建议是前后端各自开发时先约定好接口文档哪怕只用文档记录字段名和枚举值也能少返工一半。5. 关于微服务架构的取舍毕业设计要不要上微服务5.1 伪分布式 vs 单体模块化标题里提到的微服务架构我在这里可以老老实实告诉你我最终的选择没有为这个项目真正部署多个服务节点而是采用了模块化单体的架构同时预留了拆分微服务的可能性。为什么因为微服务是为了解决大型系统的特定问题而存在的团队各自独立部署、模块独立扩展、故障隔离。而一个器材管理系统的真实并发量单体应用完全能扛得住。硬把用户模块、器材模块、借用模块拆成三个SpringBoot服务加上注册中心、网关、服务间调用每个服务都要处理数据库连接和配置工作量直接翻几倍这就是所谓的“伪分布式”——看起来用了很多技术实际上每个服务都只是个空壳。用生活类比来说你在学校门口开一个水果摊不需要建一套冷链物流网络和多个仓储基地那是给全国连锁超市用的。先把手里的生意做成精品小店比堆砌一套用不上的大系统更有效。5.2 什么时候真的需要微服务我也会给老师一个合理的解释如果这个系统要部署在多个校区每个校区独立管理自己的器材库同时需要统一对外提供服务这时候按校区或按业务域拆成服务才是有意义的。微服务真正解决的是独立伸缩和独立部署的问题。比如借用系统的并发是器材管理系统的十倍只有微服务才能单独把借用模块扩容单体应用一扩容所有模块一起占资源。但在毕业设计演示场景里这些优势根本看不出来还增加了系统复杂度。5.3 不拆微服务也能做的亮点既然不硬上微服务怎么让项目有亮点我的做法是在单体架构内把代码拆成清晰的业务分层同时引入中间件增加技术含量Redis做缓存热点器材的库存数据放到缓存里降低数据库压力。定时任务每天凌晨自动扫描逾期未还的记录给相关用户生成通知。操作日志AOP用Aspect切面统一记录关键接口的操作行为做到“每一步修改都有痕迹”。Docker部署写一个docker-compose.yml把MySQL、Redis、后端、前端一键部署起来。这几个点每个都推进到位生成的系统从工程化角度看已经超过大部分毕业设计了。你甚至可以在答辩时说清楚“为什么这个规模不需要微服务”这本身就是对架构理解的体现比背概念拿的分还高。6. 部署与常见问题排查实录6.1 本地联调到打包部署本地开发完成后进入打包部署环节。后端在项目根目录执行mvn clean package生成一个可执行的Jar包前端执行npm run build生成dist静态文件目录。把前端打包进后端有两种方式一种是直接把dist里的文件复制到SpringBoot的src/main/resources/static目录再重新打包Jar另一种是前后端分别部署后端提供接口前端用Nginx托管静态文件。毕设答辩展示的时候我更推荐第二种更符合前后端分离的真实生产模式。但如果你是演示环境有限也可以选择第一种“塞进Jar”的办法一个Jar就能跑起来省去配置Nginx的麻烦。6.2 把前端打包放进SpringBoot的坑前端打包放进SpringBoot的static目录后存在一个经典问题刷新页面404。原因很简单Vue是单页面应用路由切换实际是在前端完成的后端没有对应路径。当你访问http://localhost:8080/equipment/list并刷新时SpringBoot会尝试找这个URL对应的Controller找不到就返回404。解决方案有两个一是前端路由使用hash模式URL里会有#/equipment/list刷新时不会请求后端路径二是在后端配置一个路由转发把非API的路径全部转发到index.html。毕设阶段用hash模式最省事改动一行代码就好。6.3 高频问题速查表我把自己实际踩过的坑整理成一张速查表几乎覆盖了从零搭建到上线会遇到的大部分问题问题原因解决办法前端接口全部404代理配置没生效或线上Nginx没配/api转发检查vue.config.js代理线上检查Nginx配置登录成功后刷新又跳登录用户信息只存在内存中刷新丢失使用localStorage持久化用户信息器材库存变成负数并发借出没有做库存校验或锁使用原子更新或乐观锁实现库存扣减JWT过期后接口报401前端没有统一处理token失效在axios响应拦截器里捕获401并跳转登录页数据库连接出现时区报错MySQL连接串没配置时区JDBC URL加上serverTimezoneAsia/Shanghai接口返回的日期格式串少8小时后端时区与数据库时区不一致统一配置spring.jackson.time-zoneGMT8前端打包后图标不显示静态资源路径使用了绝对路径设置Vue的publicPath为相对路径./6.4 定时任务里最容易忽视的一个小问题如果你用Scheduled做每日逾期扫描要特别注意默认情况下Spring的定时任务是单线程执行的。如果你写了两个定时任务第一个任务没跑完第二个任务会排队等待不管它们的执行时间是不是重叠的。代码实现上把定时任务单独放到一个配置类里并且给线程池加个Bean定义TaskScheduler配置线程数大于1。这个细节虽然小但能让你在答辩演示时避免“定时任务好像不执行”的尴尬。最后再分享一个小技巧也是我整个项目中受益最大的一点别急着写代码先用流程图把器材的每一个状态转换画清楚。借出、归还、报修、报废这些状态之间的转移关系一旦理清后面的数据库设计、接口设计、前端页面设计就全部顺下来了。我整个项目推进最顺利的部分恰恰是最早花了两天画流程图的那一版设计。