基于Java Spring Boot的青少年篮球俱乐部管理系统设计与实现

前阵子我帮某高校的A同学对接了一个毕业设计项目，需求方是当地一家青少年篮球俱乐部，要做一套Java Web管理系统。这种题目在毕业设计里很常见，但真正动手就会发现，“基于Java的青少年篮球俱乐部管理系统”背后牵扯的是会员资料、赛事报名、成绩统计、公告通知一整条业务链。这篇博文就围绕这个B/S架构的综合管理平台，把需求分析、数据库建模、核心代码、部署演示的全过程拆开讲一遍，适合正在做Java毕业设计、以及想给中小型培训机构做管理系统的开发者参考。

先说结论：这类系统如果只做成简单的增删改查，答辩时很容易被问住；但如果你把赛事报名流程、成绩排名计算、权限控制这三件事做扎实，它就是一个非常有说服力的项目。文章里所有表结构和代码片段均来自模拟项目，你可以直接拿去做蓝本，再按自己的业务调整。

1. 需求梳理：先搞清楚俱乐部真正缺什么

我拿到这个题目后，并没有第一时间画原型、建表，而是陪A同学去俱乐部观察了三天运营流程。俱乐部周末有6个年龄组的训练班，教练兼任报名统计，运营负责人一天要接十几个电话问课程和比赛。每天训练结束后，教练要把每个孩子的出勤和体能数据记录在纸上，月底再录入Excel。赛事报名则靠微信群接龙，经常有人重复接龙或在截止后要求补报。成绩登记更是麻烦，一场U10对抗赛打完，统计名次要花一小时。

这种场景听起来“传统”，但很真实。毕业设计的任务不是做一个花哨的软件，而是把俱乐部的真实痛点转为可执行的信息化方案。所以我给A同学定的第一步不是写代码，而是列清楚“现在哪里乱、以后怎么走”。

1.1 三个典型痛点，不只是“信息管理”

• 会员与课程档案分散：每个教练手机里都有一套自己的学员名册，学员升班、请假、退费记录混乱。家长问孩子报了几期课，教练要翻半天微信记录才能答上来。
• 赛事报名依赖人工：报名截止前要靠群公告提醒，线下核对名单，容易漏报错报。报名结束后，又有人私下找教练加塞，导致名额管理失控。
• 成绩与公告缺乏统一出口：家长想知道孩子成绩，教练要单独私发；俱乐部通知只能发群，重要信息容易被刷掉；比赛结果没有历史存档，后续做晋升参考时找不到数据。

这三个痛点决定了系统不能只是“会员信息表的增删改查”，它必须覆盖课程培训、赛事组织、成绩沉淀、公告触达四个领域，且这几个领域之间要有关联。比如赛事报名要校验会员是否在册，成绩录入要关联具体赛事和具体会员，公告已读状态要关联用户账号。这就是“一体化”的真正含义。

1.2 功能边界与角色划分

分析完痛点，需求边界就很清楚了。这个系统不是要做成OA或者ERP，核心只需要四个模块：会员管理、赛事管理、成绩管理、公告管理。在此基础上扩展出报名、课程、教练管理。

系统涉及三类使用者，我建议角色权限这样划分：

我们一开始没有做支付、退款、请假审批，因为这些不是俱乐部的核心痛点，加了反而拖慢进度。这是很多毕业设计容易犯的贪多问题——需求文档写了一大堆，最后每个功能都是半吊子。给毕设做减法，优先级反而清晰。

1.3 非功能需求：毕业设计与真实项目的差异

毕设系统与商业软件不一样，评委看的是逻辑完整、技术选型合理，不是功能越多越好。所以我和A同学明确了几个必须做到的非功能指标：

• 本地访问响应时间不超过1秒，核心列表查询避免N+1问题；
• 权限控制不能只做前端隐藏，后端接口必须有校验；
• 并发场景（比如多人同时报名）数据库层面必须防止重复；
• 数据可备份，初始化脚本可直接导入恢复。

需求优先级可以这样排：

2. 技术选型：为什么是Java + Spring Boot + Thymeleaf

技术选型是每个Java Web毕设必须回答清楚的问题。A同学原本想用JSP + Servlet，我直接建议他换成Spring Boot。这不是说Servlet不能做，而是Spring Boot能省掉大量配置，让你把精力放在业务逻辑上，答辩时也更符合当前业界主流。

2.1 B/S架构的选择理由

B/S架构即浏览器/服务器，对于篮球俱乐部这种多点访问的场景很合适。前台家长可以用手机浏览器访问，不用装客户端；管理人员在办公室电脑也能直接用。相比C/S架构，省去部署客户端的成本，系统升级时只需要重新发布服务器，访问端永远是最新版本。

从毕业设计角度，Java Web本来就是B/S教学的主流方向，评委默认你选B/S是有道理的。如果选C/S，反而要额外解释客户端连接、远程更新等问题。

2.2 后端框架组合：Spring Boot + MyBatis-Plus + Thymeleaf

这里我给的组合是：Spring Boot 2.7.x + MyBatis-Plus 3.5.x + Thymeleaf。

• Spring Boot 2.7.x：内置Tomcat，一键启动，配置简化，生态资料最多。
• MyBatis-Plus：单表增删改查不用写SQL，BaseMapper直接提供方法；复杂查询（比如多表报名统计）再写XML，分配很合理。
• Thymeleaf：服务端渲染，数据直接在HTML中填充，配合Session实现登录控制，比前后端分离更贴合单体毕设。

为什么不选Vue前后端分离？核心原因是时间和成本。A同学对Vue只停留在会写简单页面，如果硬上Vue，需要额外搭前端工程、处理跨域、写接口文档，答辩时还会被问“为什么不用服务端渲染”。当然，如果你本身已经熟练Vue，选分离架构也没问题。但对大多数毕设来说，服务端渲染的容错率更高，现场演示也更稳定。

2.3 数据库与前端模板

数据库用MySQL 8.0，免费且资料多，支持utf8mb4字符集，存储中文没问题。数据库管理工具用Navicat或者DataGrip都可以，A同学用Navicat比较多，建表、导出SQL都很顺手。

前端这边没有从头写CSS，而是用了一个开源Bootstrap后台模板，修改侧边栏和配色，换成篮球主题色。这样页面看起来专业，又不会在界面设计上耗费太多时间。毕设评审对前端的要求是“简洁、能用、不花哨”，开源模板完全够用。

2.4 环境版本建议

为什么JDK不用17或21？因为大部分高校教材、老项目仍基于JDK8，兼容性更稳，线上服务器选型也好解释。Spring Boot 2.7是2.x最后一个支持JDK8的大版本，搭配MyBatis-Plus 3.5.x不会出现版本冲突。如果你已经在用JDK11+，也可以适当升级，但没必要为了“新”而增加部署风险。

3. 数据库设计：会员、赛事、报名、成绩、公告的表怎么建

做过几个类似系统之后，我的体会是：数据库设计决定这个项目能拿多少分。业务逻辑再炫，如果表结构设计得别扭，后面接口写起来全是坑。所以这一章我会重点讲清楚核心表结构和字段思路。

3.1 核心实体与ER关系

系统的核心实体可以用文字关系图理清：

• sys_user：所有登录账号，通过role字段区分管理员、教练、会员。
• member：会员详细信息，与sys_user一对一，保存监护人信息。
• coach：教练详细信息，与sys_user一对一。
• competition：赛事表，保存报名时间、赛事时间、人数上限。
• course：课程表，对应俱乐部日常训练班。
• sign_up：通用报名表，用business_type区分报名的是赛事还是课程，这样两个报名场景共用一套逻辑。
• score：成绩表，关联赛事和会员。
• announcement：公告表，announcement_read记录哪些用户已读。

这里最核心的巧思是sign_up表的设计。很多新手会单独建competition_enroll和course_enroll两张表，逻辑重复，代码也难维护。用一张通用报名表，加一个business_type字段，就能同时支持赛事报名和课程报名，代码里只写一套报名服务。

3.2 会员表与教练表：字段设计的细节

会员表不能只存一个姓名和电话。要考虑家长是实际联系人，而且青少年篮球培训会按年龄段分组，所以字段至少要有：

• id、user_id（关联登录账号）
• name、gender、birthday、age_group
• guardian_name、guardian_phone
• membership_level（会员等级）
• status（正常/停用）
• create_time、update_time、deleted

其中deleted是逻辑删除字段。会员注册后可能中途退班，但历史报名和成绩要保留，所以不能物理删除，用逻辑删除最合适。

教练表字段相对简单：id、user_id、name、title（主教练/助教）、phone、specialty、status。可以给教练关联负责的年龄组，方便后续课程排期。

我建议把登录账号统一放在sys_user表，不要散落在会员表和教练表里。否则后面做登录和权限拦截时要联合查多张表，麻烦。sys_user表只存：id、username、password（BCrypt加密）、role、status，其他业务信息放各自资料表。

3.3 赛事表与报名表：状态字段是灵魂

赛事表的核心字段：

• id、name
• start_date、end_date、location
• age_group
• max_players
• registration_start、registration_end
• status

status我用的是字符串枚举，比如not_started、registration_open、registration_closed、finished。不建议用数字，数字状态在排查问题时还要查字典。

报名表是防超员和防重复的关键，建表语句如下：

CREATE TABLE sign_up ( id BIGINT PRIMARY KEY AUTO_INCREMENT, business_type VARCHAR(20) NOT NULL COMMENT 'competition/course', business_id BIGINT NOT NULL, member_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT '1-已报名 2-已取消 3-已确认 4-已完成', signup_time DATETIME NOT NULL, update_time DATETIME NOT NULL, UNIQUE KEY uk_business_member (business_type, business_id, member_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这个uk_business_member唯一索引极其重要。只要在数据库层加了它，同一个会员对同一场赛事或同一门课程的重复报名记录就不可能插入成功，后面我会专门讲这个坑。报名状态也要有，不能只有一条记录，因为报名后可能取消，取消后还能再次报名；如果唯一索引仍然生效，取消后重报会冲突，所以实现时要允许删除已取消的记录，或者把唯一索引改成(business_type, business_id, member_id, status)，这个细节看个人取舍。

3.4 成绩表与公告表：如何支持导出与已读统计

成绩表我设计成：

CREATE TABLE score ( id BIGINT PRIMARY KEY AUTO_INCREMENT, competition_id BIGINT NOT NULL, member_id BIGINT NOT NULL, sign_up_id BIGINT NOT NULL, score_value DECIMAL(10, 2) NOT NULL, ranking INT NOT NULL, is_qualified TINYINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

通过competition_id查某场赛事的所有成绩，通过member_id查某个会员的历史成绩。ranking字段在成绩录入后统一计算，而不是手动填，避免教练填错。如果是体能测试类项目，score_value就有意义；如果是对抗赛排名，可能不需要分数，只需要排名，所以这个表可以根据业务微调。

公告表要注意“已读统计”这个需求。如果只存公告本身，管理员想知道有多少人看过，没法查。所以要有一张announcement_read表：id、announcement_id、user_id、read_time，联合唯一索引(announcement_id, user_id)。用户第一次点击公告详情，插入读记录；管理员统计时直接count(announcement_read where announcement_id=?)即可。

公告表本身的字段：id、title、content（TEXT）、publish_time、end_time、status（草稿/已发布/已下线）。首页公告列表只查status=已发布且当前时间在publish_time和end_time之间的记录。

4. 核心功能实现：从登录到赛事报名的完整链路

数据库建好之后，接下来就是实现。我不会贴整段完整项目代码，只贴几个最有代表性的核心逻辑。如果你自己在写，可以参考这段代码去扩展。

4.1 三种角色的登录与权限拦截

登录逻辑不难，难点在于权限控制。我用的是Session + 拦截器的方案。先写一个拦截器：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); Object loginUser = session.getAttribute("loginUser"); if (loginUser == null) { response.sendRedirect("/login"); return false; } return true; } }

再注册拦截器，放行登录页、CSS、JS等静态资源。但这只能做到“登录拦截”。要区分角色，还需要在Controller或Service层继续校验。比如管理员才能删除会员，教练才能录入成绩，会员只能查看自己的成绩。

我的建议是：在Controller的方法参数中注入当前登录用户，业务方法里做归属判断。以成绩查询为例，会员只能查score.member_id = 当前登录用户关联的memberId的数据。哪怕别人猜到接口地址，也查不到不属于自己的成绩。

4.2 会员报名赛事的后端校验逻辑

这是整篇文章中最值得看的代码。报名不是一个简单的insert，它需要校验赛事状态、报名时间、人数上限、是否重复。

@Transactional(rollbackFor = Exception.class) public void signUp(Long memberId, Long competitionId) { Competition c = competitionMapper.selectById(competitionId); if (c == null || !"registration_open".equals(c.getStatus())) { throw new RuntimeException("赛事不存在或不在报名期内"); } LocalDateTime now = LocalDateTime.now(); if (now.isBefore(c.getRegistrationStart()) || now.isAfter(c.getRegistrationEnd())) { throw new RuntimeException("不在报名时间范围内"); } Long signUpCount = signUpMapper.selectCount( new LambdaQueryWrapper<SignUp>() .eq(SignUp::getBusinessType, "competition") .eq(SignUp::getBusinessId, competitionId) .eq(SignUp::getStatus, 1)); if (signUpCount >= c.getMaxPlayers()) { throw new RuntimeException("报名人数已满"); } SignUp su = new SignUp(); su.setBusinessType("competition"); su.setBusinessId(competitionId); su.setMemberId(memberId); su.setStatus(1); su.setSignupTime(now); su.setUpdateTime(now); try { signUpMapper.insert(su); } catch (DuplicateKeyException e) { throw new RuntimeException("你已经报名过这场赛事了", e); } }

这段代码里最重要的是@Transactional和DuplicateKeyException。事务保证多个数据库操作要么全部成功要么全部回滚；唯一索引是防重复报名的最后一道防线。就算两个请求几乎同时通过selectCount，最终insert时也只有一个能成功，另一个会抛异常进入catch。

如果想要更严格地防止“超员”，可以在报名时先执行一条原子更新SQL：UPDATE competition SET current_count = current_count + 1 WHERE id = ? AND current_count < max_players，影响行数为0说明名额已满。但毕业设计做到事务+唯一索引已经足够，评委问起超卖问题时，你可以提这个方案。

4.3 成绩录入与排行榜自动生成

教练录入成绩后，系统要自动计算排名。我采用“先删后插”的方式：教练在编辑页修改成绩，提交时先清空该赛事历史成绩，再按新成绩排序插入，这样排名永远是最新结果。

public void saveScore(List<ScoreItem> items, Long competitionId) { scoreMapper.delete(new LambdaQueryWrapper<Score>() .eq(Score::getCompetitionId, competitionId)); List<ScoreItem> sorted = items.stream() .sorted(Comparator.comparing(ScoreItem::getScoreValue).reversed()) .collect(Collectors.toList()); for (int i = 0; i < sorted.size(); i++) { Score s = new Score(); s.setCompetitionId(competitionId); s.setMemberId(sorted.get(i).getMemberId()); s.setScoreValue(sorted.get(i).getScoreValue()); s.setRanking(i + 1); s.setIsQualified(i < sorted.size() / 2 ? 1 : 0); scoreMapper.insert(s); } }

这里的“取前50%入围”是简化规则，真实赛事可能有更复杂的晋级规则，你可以把isQualified的计算逻辑抽成一个方法，方便后期调整。

要注意并列名次问题：如果两个会员分数相同，这个代码会依次排成1、2，而不是并列1。真实的篮球赛事更多是胜负关系或净胜分决定名次，我建议在README或论文中说明当前实现采用连续排名，适用于体能测试类项目；如果是比赛积分，需要根据实际规则计算。评委问起来，这就是一个很好的改进点。

4.4 公告发布与展示接口

公告模块最核心的就是发布和已读统计。管理员发布公告时，前端Form表单提交到后端的AnnouncementController，保存到公告表。会员登录后，公告列表查询所有status=1且当前时间在有效期的公告。如果用户已经阅读过某一条，列表项显示“已读”，否则显示“未读”。这个状态通过announcement_read表是否存在记录来判断。

我建议把已读判断放在SQL子查询里，一次查出列表和已读状态，避免在循环中逐条查数据库：

List<AnnouncementVO> list = announcementMapper.selectListWithReadStatus(userId);

对应的Mapper XML可以写一个子查询，也可以通过MyBatis-Plus的@Select注解实现。这样首页公告列表响应时间非常快，不会出现N+1查询问题。

5. 踩坑实录：那些文档里查不到的细节

这部分是A同学在开发过程中真实遇到的坑，我把它完整记录下来，希望你不用再走一遍。

5.1 字符集乱码：一次从控制台到MySQL的排查

系统跑起来后，在页面表单里输入中文“篮球训练营”，点到详情页发现变成“????”。一开始以为是数据库表没建对，用SQL查询表结构发现utf8mb4没问题。接着排查JDBC连接串，原来配置文件里写的是：

jdbc:mysql://localhost:3306/club_db?serverTimezone=Asia/Shanghai

少带了useUnicode=true&characterEncoding=utf8。MySQL连接驱动在高版本下，如果URL里不明确指定编码，就可能沿用服务器默认字符集，导致中文乱码。修改后的连接串：

jdbc:mysql://localhost:3306/club_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

同时检查了Tomcat请求编码过滤器，设置spring.thymeleaf.encoding=UTF-8，页面<meta charset="UTF-8">。这一轮排查的顺序很关键：先看数据落库有没有乱，再看请求响应编码，最后看前端页面。很多人一上来就改数据库字符集，其实问题往往出在连接串。

5.2 重复报名：唯一索引与数据库事务的正确姿势

最开始A同学没有加唯一索引，代码里只有selectCount + insert。我让他用两个浏览器同时点“立即报名”，结果数据库里出现两条同一会员同一赛事的报名记录。原因很简单：两个请求几乎同时到达后端，都在执行selectCount时发现没有重复记录，然后都走到了insert。由于没有约束，两张记录都插进去了。

解决方式就是在建表SQL中加UNIQUE KEY uk_business_member，并且报名方法加上@Transactional。数据库唯一索引是兜底，事务是保证异常时回滚。这两者配合，重复报名问题才彻底解决。

所以我的原则是：凡是涉及唯一性要求的业务，数据库层面必须有唯一索引。不要在程序里只做“先查再插”，因为那个操作不是原子的，高并发下一击就穿。

5.3 权限绕过：为什么不能只在前端隐藏按钮

A同学一开始觉得，教练登录后看不到“删除会员”按钮，权限就控制住了。直到我让他用教练账号直接请求/admin/member/delete?id=3，他发现数据被删了。原因很直接：前端只是隐藏按钮，后端接口没有任何角色校验。

解决办法是两步：第一步，用拦截器把未登录请求挡在系统外；第二步，在AdminMemberController上增加@RequireRole("ADMIN")注解，或者在Service方法里判断当前用户角色。我建议用注解+AOP的方式，代码更干净。如果你是简单的毕设，也可以在Controller里手动判断：

if (!"ADMIN".equals(currentUser.getRole())) { throw new PermissionException("无权限"); }

记住一个原则：前端隐藏只是优化体验，后端校验才是安全边界。

5.4 时间字段与日期显示的时区问题

本地Windows开发时，公告发布时间正常。部署到服务器后，页面显示的时间比实际时间晚了8个小时。这不是服务器时间不准，而是JDBC连接时区与JVM时区不一致导致的。

解决方法是统一时区。JDBC URL已经写了serverTimezone=Asia/Shanghai，还要在启动脚本里加-Duser.timezone=Asia/Shanghai。如果数据库服务器部署在海外云主机，建议在MySQL配置中设置default-time-zone='+08:00'。否则查询出来的DATETIME会出现偏移。

排查这个问题的思路：先看数据库原始值，再看Java实体类读取后的值，最后看前端展示的值。哪一步开始差了8小时，就锁定哪一层。

6. 部署与答辩演示的准备建议

很多毕设项目代码写得不错，结果现场演示时环境配置出问题，导致开不了机。这部分是实战总结，目的就是让你避免翻车。

6.1 打包前的配置修改与资源整理

打成JAR包之前，要把application.yml里的数据库连接改成目标演示环境的连接，并确认密码正确。很多同学在自己电脑上开发，数据库账号是root、密码空着，结果在演示机器上怎么都连不上数据库。

还要整理前端静态资源路径。如果使用了本地图片或上传文件，要注意Spring Boot打包后classpath路径不一定能写文件，建议把上传目录配置成外部绝对路径，例如D:/club_manager/upload/，用配置项管理。

最后写一个简单的README_部署说明.txt，包含：JDK版本、MySQL版本、数据库导入步骤、启动命令、默认账号。别小看这个文件，答辩时如果评委问“你的系统怎么部署”，你直接照着念，显得非常专业。

6.2 演示数据和一键启动脚本

我会让A同学准备一个init.sql，里面不仅建表，还插入演示数据。演示数据至少包含：

• 一个管理员账号：admin / admin123
• 一个教练账号：coach01 / coach123
• 三个会员账号：member01 / member123、member02 / member123、member03 / member123
• 两场不同状态的赛事：一场报名中，一场已结束
• 若干成绩记录和公告记录

这样登录后就能立刻看到数据，不用现场手动录入。再写一个Windows启动脚本start.bat：

@echo off chcp 65001 java -jar club-manager-0.0.1-SNAPSHOT.jar pause

双击即可启动，避免现场敲命令出幺蛾子。Linux演示环境就用java -jar club-manager.jar > log.log 2>&1 &，把日志输出到文件，方便排查。

6.3 答辩评委最爱问的问题：数据一致性、并发、安全性

• “你如何保证赛事报名不超员？”

回答要点：数据库唯一索引 + 事务 + 业务状态校验。如果评委继续追问超卖问题，你可以补充原子更新报名人数的方式，说明你知道更严格的方案。

• “权限验证是在前端还是后端？”

回答要点：前端控制菜单和按钮展示，后端拦截器控制登录，Controller/Service做角色和数据归属校验。三者配合才完整。

• “成绩排名如果有并列名次怎么办？”

回答要点：当前实现按分数降序连续排名，适合体能测试；如果是正规竞赛，可以用排名窗口函数或者按胜负关系计算，论文里可写改进方案。

• “为什么选B/S架构？”

回答要点：部署简单、升级方便、多终端访问，符合俱乐部家长和教练的使用场景。

最后再分享一个小技巧：答辩演示前，把数据库表关系图打印出来，贴在演示电脑旁边。评委问到“你怎么设计数据库”时，直接现场指着图讲，比在代码里翻实体类要清楚得多。这个项目做完，A同学最大的收获不是学会了Spring Boot，而是学会了把一个模糊的“管理系统”需求，拆成可落地的表、接口和代码。如果你也正在做类似的Java毕设，照着这个思路走，至少能少踩一半的坑。