每年毕业设计选题季，我总能在各种技术群里看到同一个问题：有没有一个既不太难、又能把前后端知识都用上的管理系统项目？如果你也有这个想法，校园体育器材管理系统是一个非常典型的切入点。这套基于 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 或 11，Spring 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> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>application.yml 的配置除了数据源信息外，还要打开 MyBatis-Plus 的驼峰映射，并设置日志输出到控制台。连接 URL 里建议携带 useUnicode=true&characterEncoding=utf8，避免中文乱码。
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 IPage<Equipment> pageQuery(Long categoryId, String keyword, Integer pageNum, Integer pageSize) { LambdaQueryWrapper<Equipment> 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查询结果用 List<Map<String, 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:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -jar demo.jar本地 IDEA 里添加 Remote JVM Debug 配置，Host 填服务器 IP，Port 填 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。启动方式常用 nohup：
nohup java -jar demo.jar > app.log 2>&1 &部署前需要重点关注三件事：数据库初始化脚本是否执行成功，application.yml 中的数据库连接地址是否指向服务器数据库，以及服务器安全组是否放通应用端口。如果数据库也在服务器本机，地址可以写 localhost；如果是云端数据库，要写实际的内网地址而不是公网地址，否则性能会受到很大影响。每次重新部署前，建议先备份数据库脚本和原 jar 包，防止新版本启动失败后无法快速回滚。
5.3 高频问题与排查技巧
我在实际跑这个项目的时候遇到过不少坑，整理成一张速查表，排查时可以快速对照：
| 现象 | 常见原因 | 解决办法 |
|---|---|---|
| 启动报数据库连接失败 | application.yml 中连接地址写错、数据库没启动、账号密码错误 | 检查 URL、端口、库名，用 mysql 客户端直连验证 |
| 中文乱码 | 连接 URL 没有指定 UTF-8 编码 | 在 URL 后加 useUnicode=true&characterEncoding=utf8 |
| 库存数量重复减少 | 借用接口没有加事务 | 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 的校园体育器材管理系统，技术上没有特别高深之处，但如果你把业务流程完整跑通、把并发和边界问题处理到位，它完全能成为一份扎实的毕业设计答卷。
