每年毕业设计选题季我总能在各种技术群里看到同一个问题有没有一个既不太难、又能把前后端知识都用上的管理系统项目如果你也有这个想法校园体育器材管理系统是一个非常典型的切入点。这套基于 Spring Boot 和 B/S 架构的校园体育器材管理系统覆盖了器材入库、借用、归还、报损、统计报表这些完整流程适合学生、教师和管理员三类角色使用。整套项目通常包含源码、数据库脚本、设计文档以及最让人头疼的远程调试环节。无论你是想把它直接作为毕设参考还是希望理解一个完整管理系统的开发链路这篇内容都能给你一份可以照着做的答案。1. 选题价值与整体设计思路1.1 校园体育器材管理到底在管什么某高校的体育器材室里最常见的场景是纸笔登记、器材随意堆放、借用损坏无人记录。学期末盘点时管理员只能对着厚厚一沓登记表人工核对效率低数据也容易丢失。这类问题的本质就是器材的“进、借、还、损、存”没有一个在线化、可追溯的载体。所以这个系统要管的核心主线其实很清楚器材从入库开始被哪个学生借走预期什么时候归还实际什么时候归还中途是否报损维修最终库存还剩多少。围绕这条主线系统需要提供器材信息维护、类别分类、库存查询、借用登记、归还登记、报损维修、统计报表等功能。很多同学做管理系统容易把页面做得花哨却忽略了业务闭环答辩时点评老师一问“这件器材已经被借出你系统里怎么避免它被再次借出”就答不上来。因此在动手设计之前先把业务状态流理清楚比急着写代码重要得多。1.2 为什么选 Spring Boot B/S架构这套组合Spring Boot 目前是 Java 后端开发的主流选择配置简单、内嵌 Tomcat、一个 jar 包就能跑起来对于毕业设计来说是很稳妥的“安全区”。B/S 架构则天然贴合校园场景浏览器访问不用在每台电脑上安装客户端。老师检查项目时只要通过浏览器输入IP就能看到系统演示成本非常低。对比传统的 C/S 架构B/S 的优势体现在三点一是跨平台Windows、macOS、Linux 都可以用浏览器打开二是部署维护方便服务端更新后所有用户拿到的都是新版本三是项目答辩时不需要准备“客户端环境”极大降低环境搭建风险。Spring Boot 的自动配置机制把大量 XML 配置变成了约定和注解让开发者把精力集中在业务逻辑上。配合 MyBatis-Plus单表 CRUD 和条件查询可以写得很简洁。网上资料也非常多遇到问题基本都能搜到解决方案这对应届生来说是很重要的一条隐性优势。1.3 角色、用例与模块划分我建议把角色分成三类普通学生用户、体育部管理员、系统管理员。学生用户登录后可以浏览器材目录、查看库存、提交借用申请、查看自己的借用记录并归还体育部管理员负责器材类别维护、器材信息录入、借用审批、归还登记、报损维修和查看统计报表系统管理员除了拥有管理员权限外还能管理用户账号。对应的功能模块可以拆成用户登录注册模块、器材类别管理模块、器材信息管理模块、借用管理模块、归还管理模块、报损维修模块、统计报表模块和个人中心模块。不要一上来把权限设计得特别重更不要引入 Spring Security 或 Shiro 这种重量级安全框架除非你想在答辩时展示额外的学习深度。对学生管理系统来说一个简单的角色字段加上拦截器做页面级权限控制已经足够。做毕设的关键是业务闭环完整而不是技术栈越复杂越好。2. 数据库设计与核心表结构2.1 实体关系梳理在写代码前先画清楚实体关系。体育器材管理系统最少需要四张表用户表 user、器材类别表 equipment_category、器材信息表 equipment、借用记录表 borrow_record。如果要把报损和维修流程做得更细可以加一张 maintain_record 表但更简单的方式是在器材信息表上用状态字段来区分“维修中”和“已报废”避免过度设计。实体之间的关系很直观一个器材类别下有多条器材信息一个用户可以创建多个借用记录一条器材信息可以关联多条借用记录。关键约束是同一器材如果有未归还的借用记录就不能被再次借出如果器材是批量库存则可用数量 stock_count 要大于等于借出数量。这里强烈建议在借用记录表中冗余保存 user_id 和 equipment_id而不是通过中间表去关联这样查询借阅历史、用户借阅列表时会非常简单也不容易出现 JOIN 过多导致性能模糊的问题。2.2 器材信息表与库存设计器材信息表是整个系统的核心。字段建议至少包含器材主键、类别ID、名称、品牌、型号、存放位置、状态、总数量、当前可用数量、单价、购入日期、创建时间、更新时间、逻辑删除标识。这里要重点解释 status 与 stock_count 的关系。有的器材是单件比如一个篮球有的器材是一批比如50副羽毛球拍。如果只用状态字段一批器材的状态就很难表达“剩余42副可用”。如果只用数量又无法表达“这件器材正在维修”。所以正确的设计是两者共存对单件器材用 status 判断是否被借出对批量器材主要看 stock_count 是否大于0同时维护一个整体状态用于展示。统一之后借用逻辑会变得非常清晰。下面是器材信息表的建表 SQL 参考CREATE TABLE equipment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT NOT NULL, name VARCHAR(100) NOT NULL, brand VARCHAR(50), model VARCHAR(50), location VARCHAR(100), status TINYINT DEFAULT 0 COMMENT 0可用 1借出 2维修 3报废, total_count INT DEFAULT 1, stock_count INT DEFAULT 1, unit_price DECIMAL(10,2), purchase_date DATE, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted TINYINT DEFAULT 0, INDEX idx_category (category_id), INDEX idx_status (status) ) COMMENT 体育器材信息表;需要注意SQL 中每个字段的注释都要写清楚数据库设计文档可以直接基于这套注释生成答辩时会被问到的概率很高。2.3 借用记录表与用户表借用记录表管理每一次借用行为的完整生命周期。字段包括借用记录ID、借用人用户ID、器材ID、借出数量、借用时间、预期归还时间、实际归还时间、状态、处理管理员ID、备注。借用记录状态建议为0 借用中1 已归还2 超期未还。其中超期未还可以通过定时任务或者查询时动态判断建议在查询时动态基于 borrow_time 和 expect_return_time 计算不必额外起一个调度任务去修改状态。用户表的设计尽量精简id、用户名、密码、真实姓名、学号、角色、手机号、创建时间。密码字段不要存明文推荐用 Spring Security 中自带的 BCryptPasswordEncoder 加密。这是一个很好的安全加分点答辩时老师通常会注意到。建表 SQL 示例就不单独展开了需要的话把 role 字段设定为 STUDENT 或 ADMIN 即可。归还逻辑要与借用记录对应起来。用户在“我的借用”里选择一条当前借用中记录点击归还后端就更新这条记录的状态同时把对应器材的 stock_count 加回来。千万不要设计成“归还时只传器材ID”这种模式否则同一用户借同一器材两次时系统无法确定归还的是哪一条记录。3. 后端核心模块实现3.1 项目搭建与依赖选型项目可以使用 Spring Initializr 初始化Java 版本选 8 或 11Spring Boot 选择 2.7.x。这个版本的资料最多跟 MyBatis-Plus 3.5.x 的兼容性也最稳。依赖中必须加入 spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok。前端如果使用 Thymeleaf 渲染再加入 spring-boot-starter-thymeleaf如果打算做前后端分离就用 Spring Boot 只提供 JSON 接口前端另起一个 Vue 工程。pom.xml 里几个关键依赖如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependencyapplication.yml 的配置除了数据源信息外还要打开 MyBatis-Plus 的驼峰映射并设置日志输出到控制台。连接 URL 里建议携带 useUnicodetruecharacterEncodingutf8避免中文乱码。3.2 器材管理模块的分层实现后端分层按 controller、service、mapper、entity 四层来写。以器材列表查询为例Controller 负责参数接收和结果包装Service 负责条件组装Mapper 使用 MyBatis-Plus 提供的方法直接查库。RestController RequestMapping(/api/equipment) public class EquipmentController { Resource private EquipmentService equipmentService; GetMapping(/list) public Result list(RequestParam(required false) Long categoryId, RequestParam(required false) String keyword, RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize) { return Result.success(equipmentService.pageQuery(categoryId, keyword, pageNum, pageSize)); } }Service 层推荐使用 LambdaQueryWrapper既安全又简洁Override public IPageEquipment pageQuery(Long categoryId, String keyword, Integer pageNum, Integer pageSize) { LambdaQueryWrapperEquipment wrapper Wrappers.lambdaQuery(); wrapper.eq(categoryId ! null, Equipment::getCategoryId, categoryId) .and(StringUtils.hasText(keyword), w - w.like(Equipment::getName, keyword) .or().like(Equipment::getBrand, keyword)); wrapper.orderByDesc(Equipment::getCreateTime); return equipmentMapper.selectPage(new Page(pageNum, pageSize), wrapper); }这里有个容易被忽略的细节分页参数不要写死在代码里。很多同学刚开始只测试第一页数据没有发现后端返回了所有数据直到前端翻页时发现数据重复才意识到问题。MyBatis-Plus 的分页插件需要在配置类里注册 PaginationInnerInterceptor否则 selectPage 不会真正分页这也是一个高频坑。3.3 借用与归还的流程控制借用逻辑是整个系统最容易出 bug 的地方。核心要求是一个用户提交借用后系统必须保证库存数量不被超扣。先用一个事务方法完成校验和扣减Transactional(rollbackFor Exception.class) public boolean borrow(Long equipmentId, Long userId, Integer num) { Equipment equipment equipmentMapper.selectById(equipmentId); if (equipment null || equipment.getDeleted() 1) { throw new BusinessException(器材不存在); } if (equipment.getStockCount() num) { throw new BusinessException(库存不足请刷新后重试); } int update equipmentMapper.reduceStock(equipmentId, num); if (update 0) { throw new BusinessException(手慢了库存已经发生变化请刷新后重试); } BorrowRecord record new BorrowRecord(); record.setEquipmentId(equipmentId); record.setUserId(userId); record.setBorrowNum(num); record.setStatus(0); borrowRecordMapper.insert(record); return true; }这里最关键的是 reduceStock 这条更新语句它在数据库层面通过条件判断保证原子性UPDATE equipment SET stock_count stock_count - #{num}, status IF(stock_count - #{num} 0, 1, status) WHERE id #{equipmentId} AND stock_count #{num}使用这条 SQL 可以让“判断库存”和“修改库存”在同一个原子操作里完成即使两个用户同时提交借用请求数据库的行锁也会保证只有一个请求更新成功。另一个请求的影响行数为0从而进入异常分支避免了库存变成负数的情况。归还逻辑就是反向操作根据借用记录ID更新状态返回时把 stock_count 加回来并设置 actual_return_time。3.4 统计报表从SQL到图表统计报表是比较容易展示个人能力的模块。常见统计维度有器材借用次数排行、每日借出数量趋势、用户借阅活跃度、逾期未归还情况。优先使用 SQL 聚合实现不要在 Java 内存里循环统计。例如统计器材借用次数排行SELECT e.name AS equipmentName, COUNT(br.id) AS borrowCount FROM borrow_record br LEFT JOIN equipment e ON br.equipment_id e.id WHERE br.borrow_time BETWEEN #{startTime} AND #{endTime} GROUP BY e.name ORDER BY borrowCount DESC查询结果用 ListMapString, Object 接收前端拿到后交给 ECharts 渲染柱状图或趋势折线图。做统计报表时要注意时间参数的边界处理BETWEEN 的结束时间应该包含当天最后一秒或者在传入时间时主动把 endTime 设为次日零点之前。否则统计结果会少算当天的数据答辩时老师如果留意到图表数据对不上会很尴尬。4. 前端页面与交互实现4.1 模板渲染还是前后端分离B/S 架构的前端有两种常见路线。一种是用 Thymeleaf 服务端模板渲染配合 Bootstrap 做样式登录状态存在 Session 里整个项目只有一个 Spring Boot 应用。另一种是 Vue Element UI 做前后端分离后端只提供 JSON 接口。对大多数毕设场景我会强烈建议选择 Thymeleaf Bootstrap。原因很现实前后端分离意味着要多维护一个前端工程、解决跨域配置、学习 Vue 的打包流程还要处理 Token 或 Session 认证问题这对时间有限、主要目标是顺利毕业的同学来说并不划算。Thymeleaf 模板可以直接使用后端查询出的数据渲染不用额外发 Ajax 请求整个调用链路很直观指导老师看起来也容易理解。如果本身对 Vue 很熟选择前后端分离当然更好但不要因为“企业都用前后端分离”这句话而盲从。4.2 器材列表与借用操作的前端实现使用 Thymeleaf 模板时器材列表页可以用 th:each 遍历数据。普通用户身份下每一条器材数据右侧显示一个“借用”按钮按钮上的>$(#borrowBtn).click(function () { var equipmentId $(this).data(id); var num $(#num_ equipmentId).val(); if (!num || num 0) { alert(请输入正确的借用数量); return; } $.post(/borrow/submit, { equipmentId: equipmentId, num: num }, function (res) { if (res.code 200) { alert(借用成功请按时归还); location.reload(); } else { alert(res.message); } }); });页面渲染时如果 stock_count 小于等于0可以直接在 Thymeleaf 中通过 th:if 禁用按钮避免用户提交无效请求。归还页面同理从“我的借用”列表选择一条当前借用中记录点击归还后把记录ID传给后端后端再执行状态更新。4.3 后台管理页面的权限控制后台管理页面的入口统一放在 /admin/ 路径下使用 Spring 拦截器做权限校验已经足够。实现时先写一个 HandlerInterceptor在 preHandle 方法里判断 Session 中的角色是否为 ADMIN如果不是重定向到登录页。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object role request.getSession().getAttribute(role); if (!ADMIN.equals(role)) { response.sendRedirect(/login); return false; } return true; } }在 WebMvcConfigurer 中注册拦截器后要特别留意放行路径。登录接口、静态资源 css/js、器材公开列表页面都需要放行否则会出现“页面整页循环重定向到登录页”的现象。如果前端是前后端分离模式拦截器还要在返回 JSON 的接口里返回 401 状态码不能直接 redirect因为前端拿到的是重定向页面而不是可解析的数据结构。5. 远程调试、打包部署与常见问题排查5.1 远程调试环境怎么搭很多同学遇到线上环境报错只能靠猜。这里分享一下远程调试的标准做法。第一种情况是环境有差异比如本地数据库和服务器数据库数据不一致这时候优先让对方提供日志文件结合日志定位上下文。第二种情况是必须实时查看运行时的变量值可以使用 JVM 的远程调试参数在服务器上以调试模式启动 jar 包java -agentlib:jdwptransportdt_socket,servery,suspendn,address5005 -jar demo.jar本地 IDEA 里添加 Remote JVM Debug 配置Host 填服务器 IPPort 填 5005启动 Debug 模式后就可以打断电跟踪。需要提醒的是服务器防火墙必须放通 5005 端口同时远程调试端口绝不能在生产环境长期开放调试完成后一定要关闭该端口或改用普通模式重启服务。这里还存在一个常见误操作服务器启动命令和本地端口冲突导致一启动就报 address already in use可以先用 netstat 查看端口占用情况。5.2 打包部署到服务器Spring Boot 项目打包非常简单只需要在 pom.xml 中引入 spring-boot-maven-plugin执行 mvn clean package 即可生成可执行的 jar。服务器端确保已经安装 JDK 8 或以上版本以及 MySQL。启动方式常用 nohupnohup java -jar demo.jar app.log 21 部署前需要重点关注三件事数据库初始化脚本是否执行成功application.yml 中的数据库连接地址是否指向服务器数据库以及服务器安全组是否放通应用端口。如果数据库也在服务器本机地址可以写 localhost如果是云端数据库要写实际的内网地址而不是公网地址否则性能会受到很大影响。每次重新部署前建议先备份数据库脚本和原 jar 包防止新版本启动失败后无法快速回滚。5.3 高频问题与排查技巧我在实际跑这个项目的时候遇到过不少坑整理成一张速查表排查时可以快速对照现象常见原因解决办法启动报数据库连接失败application.yml 中连接地址写错、数据库没启动、账号密码错误检查 URL、端口、库名用 mysql 客户端直连验证中文乱码连接 URL 没有指定 UTF-8 编码在 URL 后加 useUnicodetruecharacterEncodingutf8库存数量重复减少借用接口没有加事务Service方法上加 Transactional并将扣减SQL做成条件更新后台页面访问出现死循环重定向拦截器放行路径没包含登录页和静态资源注册拦截器时排除 /login、/css/、/js/Mapper 方法报找不到启动类没扫描到 Mapper 接口在启动类上添加 MapperScan(com.example.mapper)前端请求跨域前后端分离模式下未配置跨域后端实现 WebMvcConfigurer 或使用 CorsFilter这些坑单独看都不大但在答辩现场任何一个都可能导致演示中断。建议在答辩前一天按照“清空数据库—重新初始化—重新打包—本地启动—完整走一遍流程”的顺序做一次全量演练。6. 文档整理与答辩演示的个人经验6.1 毕业设计文档应该侧重什么文档不是代码的复制粘贴而是让老师相信你“真的思考过系统设计”。重点应该放在需求分析、ER 图、数据库设计说明、关键流程说明、测试用例和运行环境说明。需求分析要写清楚谁在使用系统、使用系统完成什么任务、当前痛点是什么。数据库设计要画出 ER 图把核心表结构的设计理由写出来比如为什么要保留 stock_count 而不是每次去统计未归还记录。测试部分不要只写“功能正常”。建议设计几个异常测试用例例如“库存为0时借用失败”“同一器材并发借出时只有一单成功”“未登录用户不能访问后台管理”等。把这些测试结果以表格形式放进文档不仅内容充实还能侧面展示你对边界情况的考虑。文档排版建议使用截图辅助但截图要重新处理避免把不必要的开发工具界面暴露出来。6.2 演示现场的准备与节奏演示项目最怕现场注册、现场录入数据。正确做法是在演示环境里提前准备好完整的示例数据包括不同类别器材、多条借用记录、不同状态的记录。演示脚本可以按照“管理员登录新增器材—学生登录查看器材—学生提交借用—管理员查看借用列表—管理员处理归还—查看统计报表”这条链路走每一步中间说清楚库存和状态的变化。如果老师要求在不同电脑上访问可以用局域网 IP 而不是 localhost。提前测试防火墙和网络策略避免演示现场无法访问。如果准备了远端服务器也要先确认服务器时间、时区、数据库时间和本地保持一致否则报表模块的时间趋势会显示异常。准备一个 PDF 版的项目部署说明也非常有用老师如果需要把项目拷走一份说明文档能省掉大量沟通成本。6.3 我在实操中的几点体会最后分享几条做这类管理系统项目最核心的体会。一是别急着写代码先把“一件器材同一时间只能被一条未归还记录占用”这类业务规则理清楚数据模型对了后面编码就是体力活。二是先做最小闭环登录、器材列表、借用、归还这条流程跑通之后再补统计报表、权限细节和页面美化不要一开始就陷入某个页面样式里。三是维护好两个东西数据库初始化脚本和可复现的启动文档。无论中途改了多少次代码只要这两个东西是完整的项目就随时可以从零恢复。这套基于 Spring Boot 的校园体育器材管理系统技术上没有特别高深之处但如果你把业务流程完整跑通、把并发和边界问题处理到位它完全能成为一份扎实的毕业设计答卷。
每年毕业设计选题季我总能在各种技术群里看到同一个问题有没有一个既不太难、又能把前后端知识都用上的管理系统项目如果你也有这个想法校园体育器材管理系统是一个非常典型的切入点。这套基于 Spring Boot 和 B/S 架构的校园体育器材管理系统覆盖了器材入库、借用、归还、报损、统计报表这些完整流程适合学生、教师和管理员三类角色使用。整套项目通常包含源码、数据库脚本、设计文档以及最让人头疼的远程调试环节。无论你是想把它直接作为毕设参考还是希望理解一个完整管理系统的开发链路这篇内容都能给你一份可以照着做的答案。1. 选题价值与整体设计思路1.1 校园体育器材管理到底在管什么某高校的体育器材室里最常见的场景是纸笔登记、器材随意堆放、借用损坏无人记录。学期末盘点时管理员只能对着厚厚一沓登记表人工核对效率低数据也容易丢失。这类问题的本质就是器材的“进、借、还、损、存”没有一个在线化、可追溯的载体。所以这个系统要管的核心主线其实很清楚器材从入库开始被哪个学生借走预期什么时候归还实际什么时候归还中途是否报损维修最终库存还剩多少。围绕这条主线系统需要提供器材信息维护、类别分类、库存查询、借用登记、归还登记、报损维修、统计报表等功能。很多同学做管理系统容易把页面做得花哨却忽略了业务闭环答辩时点评老师一问“这件器材已经被借出你系统里怎么避免它被再次借出”就答不上来。因此在动手设计之前先把业务状态流理清楚比急着写代码重要得多。1.2 为什么选 Spring Boot B/S架构这套组合Spring Boot 目前是 Java 后端开发的主流选择配置简单、内嵌 Tomcat、一个 jar 包就能跑起来对于毕业设计来说是很稳妥的“安全区”。B/S 架构则天然贴合校园场景浏览器访问不用在每台电脑上安装客户端。老师检查项目时只要通过浏览器输入IP就能看到系统演示成本非常低。对比传统的 C/S 架构B/S 的优势体现在三点一是跨平台Windows、macOS、Linux 都可以用浏览器打开二是部署维护方便服务端更新后所有用户拿到的都是新版本三是项目答辩时不需要准备“客户端环境”极大降低环境搭建风险。Spring Boot 的自动配置机制把大量 XML 配置变成了约定和注解让开发者把精力集中在业务逻辑上。配合 MyBatis-Plus单表 CRUD 和条件查询可以写得很简洁。网上资料也非常多遇到问题基本都能搜到解决方案这对应届生来说是很重要的一条隐性优势。1.3 角色、用例与模块划分我建议把角色分成三类普通学生用户、体育部管理员、系统管理员。学生用户登录后可以浏览器材目录、查看库存、提交借用申请、查看自己的借用记录并归还体育部管理员负责器材类别维护、器材信息录入、借用审批、归还登记、报损维修和查看统计报表系统管理员除了拥有管理员权限外还能管理用户账号。对应的功能模块可以拆成用户登录注册模块、器材类别管理模块、器材信息管理模块、借用管理模块、归还管理模块、报损维修模块、统计报表模块和个人中心模块。不要一上来把权限设计得特别重更不要引入 Spring Security 或 Shiro 这种重量级安全框架除非你想在答辩时展示额外的学习深度。对学生管理系统来说一个简单的角色字段加上拦截器做页面级权限控制已经足够。做毕设的关键是业务闭环完整而不是技术栈越复杂越好。2. 数据库设计与核心表结构2.1 实体关系梳理在写代码前先画清楚实体关系。体育器材管理系统最少需要四张表用户表 user、器材类别表 equipment_category、器材信息表 equipment、借用记录表 borrow_record。如果要把报损和维修流程做得更细可以加一张 maintain_record 表但更简单的方式是在器材信息表上用状态字段来区分“维修中”和“已报废”避免过度设计。实体之间的关系很直观一个器材类别下有多条器材信息一个用户可以创建多个借用记录一条器材信息可以关联多条借用记录。关键约束是同一器材如果有未归还的借用记录就不能被再次借出如果器材是批量库存则可用数量 stock_count 要大于等于借出数量。这里强烈建议在借用记录表中冗余保存 user_id 和 equipment_id而不是通过中间表去关联这样查询借阅历史、用户借阅列表时会非常简单也不容易出现 JOIN 过多导致性能模糊的问题。2.2 器材信息表与库存设计器材信息表是整个系统的核心。字段建议至少包含器材主键、类别ID、名称、品牌、型号、存放位置、状态、总数量、当前可用数量、单价、购入日期、创建时间、更新时间、逻辑删除标识。这里要重点解释 status 与 stock_count 的关系。有的器材是单件比如一个篮球有的器材是一批比如50副羽毛球拍。如果只用状态字段一批器材的状态就很难表达“剩余42副可用”。如果只用数量又无法表达“这件器材正在维修”。所以正确的设计是两者共存对单件器材用 status 判断是否被借出对批量器材主要看 stock_count 是否大于0同时维护一个整体状态用于展示。统一之后借用逻辑会变得非常清晰。下面是器材信息表的建表 SQL 参考CREATE TABLE equipment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT NOT NULL, name VARCHAR(100) NOT NULL, brand VARCHAR(50), model VARCHAR(50), location VARCHAR(100), status TINYINT DEFAULT 0 COMMENT 0可用 1借出 2维修 3报废, total_count INT DEFAULT 1, stock_count INT DEFAULT 1, unit_price DECIMAL(10,2), purchase_date DATE, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted TINYINT DEFAULT 0, INDEX idx_category (category_id), INDEX idx_status (status) ) COMMENT 体育器材信息表;需要注意SQL 中每个字段的注释都要写清楚数据库设计文档可以直接基于这套注释生成答辩时会被问到的概率很高。2.3 借用记录表与用户表借用记录表管理每一次借用行为的完整生命周期。字段包括借用记录ID、借用人用户ID、器材ID、借出数量、借用时间、预期归还时间、实际归还时间、状态、处理管理员ID、备注。借用记录状态建议为0 借用中1 已归还2 超期未还。其中超期未还可以通过定时任务或者查询时动态判断建议在查询时动态基于 borrow_time 和 expect_return_time 计算不必额外起一个调度任务去修改状态。用户表的设计尽量精简id、用户名、密码、真实姓名、学号、角色、手机号、创建时间。密码字段不要存明文推荐用 Spring Security 中自带的 BCryptPasswordEncoder 加密。这是一个很好的安全加分点答辩时老师通常会注意到。建表 SQL 示例就不单独展开了需要的话把 role 字段设定为 STUDENT 或 ADMIN 即可。归还逻辑要与借用记录对应起来。用户在“我的借用”里选择一条当前借用中记录点击归还后端就更新这条记录的状态同时把对应器材的 stock_count 加回来。千万不要设计成“归还时只传器材ID”这种模式否则同一用户借同一器材两次时系统无法确定归还的是哪一条记录。3. 后端核心模块实现3.1 项目搭建与依赖选型项目可以使用 Spring Initializr 初始化Java 版本选 8 或 11Spring Boot 选择 2.7.x。这个版本的资料最多跟 MyBatis-Plus 3.5.x 的兼容性也最稳。依赖中必须加入 spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok。前端如果使用 Thymeleaf 渲染再加入 spring-boot-starter-thymeleaf如果打算做前后端分离就用 Spring Boot 只提供 JSON 接口前端另起一个 Vue 工程。pom.xml 里几个关键依赖如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependencyapplication.yml 的配置除了数据源信息外还要打开 MyBatis-Plus 的驼峰映射并设置日志输出到控制台。连接 URL 里建议携带 useUnicodetruecharacterEncodingutf8避免中文乱码。3.2 器材管理模块的分层实现后端分层按 controller、service、mapper、entity 四层来写。以器材列表查询为例Controller 负责参数接收和结果包装Service 负责条件组装Mapper 使用 MyBatis-Plus 提供的方法直接查库。RestController RequestMapping(/api/equipment) public class EquipmentController { Resource private EquipmentService equipmentService; GetMapping(/list) public Result list(RequestParam(required false) Long categoryId, RequestParam(required false) String keyword, RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize) { return Result.success(equipmentService.pageQuery(categoryId, keyword, pageNum, pageSize)); } }Service 层推荐使用 LambdaQueryWrapper既安全又简洁Override public IPageEquipment pageQuery(Long categoryId, String keyword, Integer pageNum, Integer pageSize) { LambdaQueryWrapperEquipment wrapper Wrappers.lambdaQuery(); wrapper.eq(categoryId ! null, Equipment::getCategoryId, categoryId) .and(StringUtils.hasText(keyword), w - w.like(Equipment::getName, keyword) .or().like(Equipment::getBrand, keyword)); wrapper.orderByDesc(Equipment::getCreateTime); return equipmentMapper.selectPage(new Page(pageNum, pageSize), wrapper); }这里有个容易被忽略的细节分页参数不要写死在代码里。很多同学刚开始只测试第一页数据没有发现后端返回了所有数据直到前端翻页时发现数据重复才意识到问题。MyBatis-Plus 的分页插件需要在配置类里注册 PaginationInnerInterceptor否则 selectPage 不会真正分页这也是一个高频坑。3.3 借用与归还的流程控制借用逻辑是整个系统最容易出 bug 的地方。核心要求是一个用户提交借用后系统必须保证库存数量不被超扣。先用一个事务方法完成校验和扣减Transactional(rollbackFor Exception.class) public boolean borrow(Long equipmentId, Long userId, Integer num) { Equipment equipment equipmentMapper.selectById(equipmentId); if (equipment null || equipment.getDeleted() 1) { throw new BusinessException(器材不存在); } if (equipment.getStockCount() num) { throw new BusinessException(库存不足请刷新后重试); } int update equipmentMapper.reduceStock(equipmentId, num); if (update 0) { throw new BusinessException(手慢了库存已经发生变化请刷新后重试); } BorrowRecord record new BorrowRecord(); record.setEquipmentId(equipmentId); record.setUserId(userId); record.setBorrowNum(num); record.setStatus(0); borrowRecordMapper.insert(record); return true; }这里最关键的是 reduceStock 这条更新语句它在数据库层面通过条件判断保证原子性UPDATE equipment SET stock_count stock_count - #{num}, status IF(stock_count - #{num} 0, 1, status) WHERE id #{equipmentId} AND stock_count #{num}使用这条 SQL 可以让“判断库存”和“修改库存”在同一个原子操作里完成即使两个用户同时提交借用请求数据库的行锁也会保证只有一个请求更新成功。另一个请求的影响行数为0从而进入异常分支避免了库存变成负数的情况。归还逻辑就是反向操作根据借用记录ID更新状态返回时把 stock_count 加回来并设置 actual_return_time。3.4 统计报表从SQL到图表统计报表是比较容易展示个人能力的模块。常见统计维度有器材借用次数排行、每日借出数量趋势、用户借阅活跃度、逾期未归还情况。优先使用 SQL 聚合实现不要在 Java 内存里循环统计。例如统计器材借用次数排行SELECT e.name AS equipmentName, COUNT(br.id) AS borrowCount FROM borrow_record br LEFT JOIN equipment e ON br.equipment_id e.id WHERE br.borrow_time BETWEEN #{startTime} AND #{endTime} GROUP BY e.name ORDER BY borrowCount DESC查询结果用 ListMapString, Object 接收前端拿到后交给 ECharts 渲染柱状图或趋势折线图。做统计报表时要注意时间参数的边界处理BETWEEN 的结束时间应该包含当天最后一秒或者在传入时间时主动把 endTime 设为次日零点之前。否则统计结果会少算当天的数据答辩时老师如果留意到图表数据对不上会很尴尬。4. 前端页面与交互实现4.1 模板渲染还是前后端分离B/S 架构的前端有两种常见路线。一种是用 Thymeleaf 服务端模板渲染配合 Bootstrap 做样式登录状态存在 Session 里整个项目只有一个 Spring Boot 应用。另一种是 Vue Element UI 做前后端分离后端只提供 JSON 接口。对大多数毕设场景我会强烈建议选择 Thymeleaf Bootstrap。原因很现实前后端分离意味着要多维护一个前端工程、解决跨域配置、学习 Vue 的打包流程还要处理 Token 或 Session 认证问题这对时间有限、主要目标是顺利毕业的同学来说并不划算。Thymeleaf 模板可以直接使用后端查询出的数据渲染不用额外发 Ajax 请求整个调用链路很直观指导老师看起来也容易理解。如果本身对 Vue 很熟选择前后端分离当然更好但不要因为“企业都用前后端分离”这句话而盲从。4.2 器材列表与借用操作的前端实现使用 Thymeleaf 模板时器材列表页可以用 th:each 遍历数据。普通用户身份下每一条器材数据右侧显示一个“借用”按钮按钮上的>$(#borrowBtn).click(function () { var equipmentId $(this).data(id); var num $(#num_ equipmentId).val(); if (!num || num 0) { alert(请输入正确的借用数量); return; } $.post(/borrow/submit, { equipmentId: equipmentId, num: num }, function (res) { if (res.code 200) { alert(借用成功请按时归还); location.reload(); } else { alert(res.message); } }); });页面渲染时如果 stock_count 小于等于0可以直接在 Thymeleaf 中通过 th:if 禁用按钮避免用户提交无效请求。归还页面同理从“我的借用”列表选择一条当前借用中记录点击归还后把记录ID传给后端后端再执行状态更新。4.3 后台管理页面的权限控制后台管理页面的入口统一放在 /admin/ 路径下使用 Spring 拦截器做权限校验已经足够。实现时先写一个 HandlerInterceptor在 preHandle 方法里判断 Session 中的角色是否为 ADMIN如果不是重定向到登录页。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object role request.getSession().getAttribute(role); if (!ADMIN.equals(role)) { response.sendRedirect(/login); return false; } return true; } }在 WebMvcConfigurer 中注册拦截器后要特别留意放行路径。登录接口、静态资源 css/js、器材公开列表页面都需要放行否则会出现“页面整页循环重定向到登录页”的现象。如果前端是前后端分离模式拦截器还要在返回 JSON 的接口里返回 401 状态码不能直接 redirect因为前端拿到的是重定向页面而不是可解析的数据结构。5. 远程调试、打包部署与常见问题排查5.1 远程调试环境怎么搭很多同学遇到线上环境报错只能靠猜。这里分享一下远程调试的标准做法。第一种情况是环境有差异比如本地数据库和服务器数据库数据不一致这时候优先让对方提供日志文件结合日志定位上下文。第二种情况是必须实时查看运行时的变量值可以使用 JVM 的远程调试参数在服务器上以调试模式启动 jar 包java -agentlib:jdwptransportdt_socket,servery,suspendn,address5005 -jar demo.jar本地 IDEA 里添加 Remote JVM Debug 配置Host 填服务器 IPPort 填 5005启动 Debug 模式后就可以打断电跟踪。需要提醒的是服务器防火墙必须放通 5005 端口同时远程调试端口绝不能在生产环境长期开放调试完成后一定要关闭该端口或改用普通模式重启服务。这里还存在一个常见误操作服务器启动命令和本地端口冲突导致一启动就报 address already in use可以先用 netstat 查看端口占用情况。5.2 打包部署到服务器Spring Boot 项目打包非常简单只需要在 pom.xml 中引入 spring-boot-maven-plugin执行 mvn clean package 即可生成可执行的 jar。服务器端确保已经安装 JDK 8 或以上版本以及 MySQL。启动方式常用 nohupnohup java -jar demo.jar app.log 21 部署前需要重点关注三件事数据库初始化脚本是否执行成功application.yml 中的数据库连接地址是否指向服务器数据库以及服务器安全组是否放通应用端口。如果数据库也在服务器本机地址可以写 localhost如果是云端数据库要写实际的内网地址而不是公网地址否则性能会受到很大影响。每次重新部署前建议先备份数据库脚本和原 jar 包防止新版本启动失败后无法快速回滚。5.3 高频问题与排查技巧我在实际跑这个项目的时候遇到过不少坑整理成一张速查表排查时可以快速对照现象常见原因解决办法启动报数据库连接失败application.yml 中连接地址写错、数据库没启动、账号密码错误检查 URL、端口、库名用 mysql 客户端直连验证中文乱码连接 URL 没有指定 UTF-8 编码在 URL 后加 useUnicodetruecharacterEncodingutf8库存数量重复减少借用接口没有加事务Service方法上加 Transactional并将扣减SQL做成条件更新后台页面访问出现死循环重定向拦截器放行路径没包含登录页和静态资源注册拦截器时排除 /login、/css/、/js/Mapper 方法报找不到启动类没扫描到 Mapper 接口在启动类上添加 MapperScan(com.example.mapper)前端请求跨域前后端分离模式下未配置跨域后端实现 WebMvcConfigurer 或使用 CorsFilter这些坑单独看都不大但在答辩现场任何一个都可能导致演示中断。建议在答辩前一天按照“清空数据库—重新初始化—重新打包—本地启动—完整走一遍流程”的顺序做一次全量演练。6. 文档整理与答辩演示的个人经验6.1 毕业设计文档应该侧重什么文档不是代码的复制粘贴而是让老师相信你“真的思考过系统设计”。重点应该放在需求分析、ER 图、数据库设计说明、关键流程说明、测试用例和运行环境说明。需求分析要写清楚谁在使用系统、使用系统完成什么任务、当前痛点是什么。数据库设计要画出 ER 图把核心表结构的设计理由写出来比如为什么要保留 stock_count 而不是每次去统计未归还记录。测试部分不要只写“功能正常”。建议设计几个异常测试用例例如“库存为0时借用失败”“同一器材并发借出时只有一单成功”“未登录用户不能访问后台管理”等。把这些测试结果以表格形式放进文档不仅内容充实还能侧面展示你对边界情况的考虑。文档排版建议使用截图辅助但截图要重新处理避免把不必要的开发工具界面暴露出来。6.2 演示现场的准备与节奏演示项目最怕现场注册、现场录入数据。正确做法是在演示环境里提前准备好完整的示例数据包括不同类别器材、多条借用记录、不同状态的记录。演示脚本可以按照“管理员登录新增器材—学生登录查看器材—学生提交借用—管理员查看借用列表—管理员处理归还—查看统计报表”这条链路走每一步中间说清楚库存和状态的变化。如果老师要求在不同电脑上访问可以用局域网 IP 而不是 localhost。提前测试防火墙和网络策略避免演示现场无法访问。如果准备了远端服务器也要先确认服务器时间、时区、数据库时间和本地保持一致否则报表模块的时间趋势会显示异常。准备一个 PDF 版的项目部署说明也非常有用老师如果需要把项目拷走一份说明文档能省掉大量沟通成本。6.3 我在实操中的几点体会最后分享几条做这类管理系统项目最核心的体会。一是别急着写代码先把“一件器材同一时间只能被一条未归还记录占用”这类业务规则理清楚数据模型对了后面编码就是体力活。二是先做最小闭环登录、器材列表、借用、归还这条流程跑通之后再补统计报表、权限细节和页面美化不要一开始就陷入某个页面样式里。三是维护好两个东西数据库初始化脚本和可复现的启动文档。无论中途改了多少次代码只要这两个东西是完整的项目就随时可以从零恢复。这套基于 Spring Boot 的校园体育器材管理系统技术上没有特别高深之处但如果你把业务流程完整跑通、把并发和边界问题处理到位它完全能成为一份扎实的毕业设计答卷。
