Java健身俱乐部管理系统实战：Spring Boot+MyBatis-Plus工程落地指南

简介：这是一套基于Java开发的健身俱乐部信息管理系统，面向计算机专业初学者与课程设计实践者，解决中小型健身场馆会员管理、员工调度、器材维护等核心运营需求。系统采用B/S三层架构，后端以Java实现业务逻辑，前端提供简洁交互界面，数据库选用MySQL，具备修改密码、工作人员管理、会员卡类型设置、会员资料维护、健身器材登记、教练执教安排及安全退出七大功能模块，操作直观、提示友好，适合Java Web入门项目实训与毕业设计参考。资源包共7个文件，含3张系统运行界面截图（jpg）、2个压缩包（源代码jianshen.zip与论文zip）、1个SQL建库脚本（db_jianshen2017_g.sql）和1个必读说明txt，整体大小19.44MB，结构清晰、开箱即用。目前已有195人学习下载，读者可直接导入数据库、部署运行并对照截图理解各模块交互逻辑，快速掌握Java+MySQL+B/S架构的完整开发流程。

1. 为什么一个“Java健身俱乐部管理系统”能成为校招面试官手里的压轴题？

不是因为系统有多炫——它没有AI推荐私教、不接智能手环实时心率、连微信扫码签到都得手动补个二维码生成器。恰恰相反，它被反复考、反复写、反复部署在学生简历里，是因为它是一块精准的工程能力试金石：它必须同时扛住「业务逻辑的毛刺感」（会员续费规则嵌套、私教课时冻结与解冻、器械预约冲突检测）、「数据关系的缠绕度」（会员↔私教↔课程↔场馆↔器械↔消费记录↔储值流水，七张表以上强关联）和「工程落地的粗糙面」（没Docker、没CI/CD、甚至没Nginx反代，就靠Tomcat裸跑+MySQL本地库+IDEA一键启动）。我带过3届实习工程师，凡是能把这个系统从零搭起、调通储值扣费链路、跑通预约冲突校验、并在MySQL里手写一条带LEFT JOIN + GROUP BY + HAVING COUNT(*) > 1的器械占用热力SQL的人，Java基础、SQL直觉、事务边界意识、异常分支覆盖能力，基本过关。它不考你多会写Lambda，而考你try-catch-finally里finally是否真关了数据库连接；不考你Spring Boot自动装配多优雅，而考你@Transactional加在Service层方法上时，若该方法被本类另一个非事务方法调用，事务为何失效——这才是企业级Java开发每天踩的坑。如果你正卡在“写了CRUD但不敢改业务逻辑”“能跑但一加并发就报错”“MyBatis查不出数据却死活找不到SQL在哪”，这篇笔记就是为你写的。

2. 从零搭起：用Spring Boot + MyBatis-Plus + MySQL 8.0 构建最小可运行骨架

这个系统不是玩具，它要能真实支撑一家中型健身俱乐部的日常运营：500+会员、20+私教、8个场馆、30+台器械、日均200+预约。所以骨架必须轻但不脆，扩展有缝但不松垮。我们放弃Shiro（太重）、跳过Redis（初期无缓存需求）、不用Vue前后端分离（先保Java后端闭环），用最稳的组合：Spring Boot 2.7.18（兼容JDK 8，避免新版本依赖冲突）、MyBatis-Plus 3.5.3.1（代码生成器成熟、分页插件开箱即用）、MySQL 8.0.33（支持窗口函数，为后续课时统计埋点）。

2.1 创建项目并初始化核心依赖

用Spring Initializr生成基础项目（JDK 8、Maven、Spring Web、Lombok），再手动追加关键依赖。注意：不要直接选MyBatis Starter，MyBatis-Plus会自带MyBatis核心，重复引入易引发MapperScannerConfigurer冲突。

<!-- pom.xml --> <dependencies> <!-- Spring Boot Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- Lombok 简化POJO --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <!-- MyBatis-Plus 核心 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <!-- MySQL 驱动（8.0+需用mysql-connector-java 8.0.33） --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> <version>8.0.33</version> </dependency> <!-- HikariCP 连接池（Spring Boot 2.7默认） --> <dependency> <groupId>com.zaxxer</groupId> <artifactId>HikariCP</artifactId> </dependency> </dependencies>

提示：mysql-connector-java8.0.33 是关键。低于8.0.30的驱动在MySQL 8.0.33上可能触发Public Key Retrieval is not allowed错误，这是驱动与服务端RSA密钥交换协议不匹配导致的。别信网上“加allowPublicKeyRetrieval=true”的野路子，那只是掩盖问题——换对版本才是根治。

2.2 配置application.yml：连接池与MyBatis-Plus行为控制

配置不是填空，是设防。HikariCP的maximumPoolSize不能拍脑袋定20，要按公式算：CPU核数 × (1 + 等待时间/工作时间)。健身系统IO密集（查预约、写消费），我们按4核服务器、平均等待300ms、工作100ms估算，取4 × (1 + 3) = 16，再留2个余量，设为18。MyBatis-Plus的configuration.map-underscore-to-camel-case: true必须开，否则member_name字段永远映射不到memberName属性——这是新手最常翻车的“查不到数据”根源。

# src/main/resources/application.yml spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/fitness_club?useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=false username: root password: your_password hikari: maximum-pool-size: 18 minimum-idle: 4 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 开发期打印SQL global-config: db-config: id-type: assign_id # 使用雪花算法生成ID，避免MySQL自增主键暴露业务量 table-prefix: t_ # 所有表加t_前缀，与系统表隔离

2.3 用MyBatis-Plus代码生成器：一键生成实体、Mapper、Service、Controller

别手敲7张表的14个Java类。MyBatis-Plus的AutoGenerator是救命稻草。重点在StrategyConfig：setInclude()必须精确列出你要生成的表名（如"t_member", "t_coach", "t_course"），绝不能写setExclude()——排除漏一个，后面业务就断。Entity类要加@TableName("t_member")，否则MP找不到表；@TableId(type = IdType.ASSIGN_ID)确保ID是Long型雪花ID，而非数据库自增int。

// 代码生成器入口类（放在test目录下，运行一次生成即可） public class CodeGenerator { public static void main(String[] args) { AutoGenerator generator = new AutoGenerator(); // 1. 全局配置 GlobalConfig gc = new GlobalConfig(); gc.setOutputDir(System.getProperty("user.dir") + "/src/main/java"); gc.setAuthor("your_name"); gc.setOpen(false); // 生成后不自动打开文件夹 gc.setSwagger2(true); // 启用Swagger注解 generator.setGlobalConfig(gc); // 2. 数据源配置 DataSourceConfig dsc = new DataSourceConfig(); dsc.setUrl("jdbc:mysql://localhost:3306/fitness_club?useSSL=false&serverTimezone=Asia/Shanghai"); dsc.setDriverName("com.mysql.cj.jdbc.Driver"); dsc.setUsername("root"); dsc.setPassword("your_password"); generator.setDataSource(dsc); // 3. 包配置 PackageConfig pc = new PackageConfig(); pc.setModuleName("system"); // 模块名，生成在com.example.fitness.system下 pc.setParent("com.example.fitness"); generator.setPackageInfo(pc); // 4. 策略配置：关键！指定表名 StrategyConfig strategy = new StrategyConfig(); strategy.setNaming(NamingStrategy.underline_to_camel); // 数据库下划线转驼峰 strategy.setColumnNaming(NamingStrategy.underline_to_camel); strategy.setEntityLombokModel(true); // 自动添加Lombok注解 strategy.setRestControllerStyle(true); strategy.setInclude("t_member", "t_coach", "t_course", "t_reservation", "t_equipment"); // 必须显式列出 strategy.setControllerMappingHyphenStyle(true); generator.setStrategy(strategy); generator.execute(); } }

执行后，你会得到Member.java（含@TableName("t_member")）、MemberMapper.java（继承BaseMapper<Member>）、MemberService.java（含save()、list()等默认方法）、MemberController.java（带@RestController和@RequestMapping("/member")）。此时立刻编译运行：如果报NoSuchBeanDefinitionException: No qualifying bean of type 'com.example.fitness.system.mapper.MemberMapper'，90%是MemberMapper接口没加@Mapper注解或没被@MapperScan扫描到——检查生成的Mapper接口顶部是否有@Mapper，若没有，在Application.java上加@MapperScan("com.example.fitness.system.mapper")。

3. 业务落地：把“会员续费”和“器械预约冲突”从需求文档变成可验证的Java代码

骨架搭好，真正的硬仗才开始。健身系统的核心不是增删改查，而是状态流转的严谨性：会员卡过期后能否续费？私教课时用完是否自动停课？预约器械时，同一时段同一器械是否允许被两人抢订？这些不是if-else能穷举的，必须用事务+唯一约束+应用层校验三层兜底。我们以两个高频场景为例，给出可直接抄作业的实现。

3.1 会员续费：状态机驱动的原子操作

会员续费不是简单更新expire_date。它涉及：1）检查当前状态是否允许续费（不能是已注销、冻结状态）；2）计算新到期日（原到期日+购买月数，不是当前日期+月数）；3）生成储值流水；4）更新会员状态。四步必须在一个事务内完成，否则出现“钱扣了但卡没续上”的资损。

@Service public class MemberService extends ServiceImpl<MemberMapper, Member> { @Autowired private StorageRecordService storageRecordService; @Transactional(rollbackFor = Exception.class) public boolean renewMembership(Long memberId, Integer months) { // 1. 查询并锁住会员记录（防止并发续费） Member member = this.getById(memberId); if (member == null || !MemberStatus.ACTIVE.getValue().equals(member.getStatus())) { throw new RuntimeException("会员不存在或状态不可续费"); } // 2. 计算新到期日：从当前到期日开始延展，不是从今天开始 LocalDate newExpireDate = member.getExpireDate().plusMonths(months); // 3. 更新会员信息（只更新到期日和更新时间） Member updateMember = new Member(); updateMember.setId(memberId); updateMember.setExpireDate(newExpireDate); updateMember.setUpdateTime(LocalDateTime.now()); this.updateById(updateMember); // 4. 生成储值流水（关联会员、金额、类型） StorageRecord record = new StorageRecord(); record.setMemberId(memberId); record.setAmount(months * 200.0); // 假设每月200元 record.setType(StorageType.RENEWAL.getValue()); // 续费类型 record.setCreateTime(LocalDateTime.now()); storageRecordService.save(record); return true; } }

参数说明：months是购买月数，200.0是单价，实际应从配置中心或数据库读取。MemberStatus.ACTIVE是枚举类，值为"active"，避免硬编码字符串。@Transactional加在renewMembership方法上，确保整个流程原子性；rollbackFor = Exception.class保证所有异常都回滚，不只是RuntimeException。

3.2 器械预约冲突检测：数据库唯一索引 + 应用层双重校验

预约冲突是典型“查-判-写”场景，极易因并发导致超卖。比如两用户同时预约同一台器械的同一时段。仅靠应用层SELECT COUNT(*)判断再INSERT，必然失败。必须用数据库唯一索引强制排他，再辅以应用层友好提示。

第一步：在reservation表上建联合唯一索引，覆盖equipment_id + start_time + end_time。注意：start_time和end_time是datetime类型，索引能精确到秒。

-- MySQL命令行执行 ALTER TABLE t_reservation ADD UNIQUE INDEX uk_equipment_time (equipment_id, start_time, end_time);

第二步：应用层插入前，先用MyBatis-Plus的lambdaQuery查是否存在重叠预约。这里的关键是时间重叠的SQL逻辑：A.start < B.end AND A.end > B.start。我们查equipment_id相同、且与新预约时段重叠的所有记录。

@Service public class ReservationService extends ServiceImpl<ReservationMapper, Reservation> { public boolean createReservation(Reservation reservation) { Long equipmentId = reservation.getEquipmentId(); LocalDateTime startTime = reservation.getStartTime(); LocalDateTime endTime = reservation.getEndTime(); // 应用层预检：查是否有重叠预约（非精确相等，是区间重叠） QueryWrapper<Reservation> overlapQw = new QueryWrapper<>(); overlapQw.eq("equipment_id", equipmentId) .and(i -> i.lt("start_time", endTime).gt("end_time", startTime)); long overlapCount = this.count(overlapQw); if (overlapCount > 0) { throw new RuntimeException("该器械在选定时段已被预约，请选择其他时间"); } // 尝试插入，唯一索引会拦截并发冲突 try { return this.save(reservation); } catch (DuplicateKeyException e) { // 唯一索引冲突，说明并发下另一请求已插入成功 throw new RuntimeException("预约失败：该时段已被他人抢先预约，请刷新后重试"); } } }

为什么需要双重校验？单靠唯一索引，用户看到的是冰冷的Duplicate entry 'xxx' for key 'uk_equipment_time'；单靠应用层查询，高并发下仍可能超卖。两者结合：应用层提供友好提示（“已被预约”），唯一索引兜底保证数据绝对正确（“绝不超卖”）。这是生产环境必须的防御性编程。

4. 避坑指南：我在5个真实项目里踩过的7个血泪坑

这个系统看似简单，但每个模块都藏着让开发者深夜抓狂的暗礁。以下是我亲手调试、线上复现、最终定位到根因的7个典型问题，按发生频率排序，每条都附带可复现的场景、根本原因和一行解决命令。

4.1 现象：MemberController返回JSON时，中文全是乱码{"name":"有效"}

原因：Spring Boot 2.7默认字符集是UTF-8，但Tomcat 9.x在Windows环境下可能读取系统默认编码（GBK）。当@ResponseBody序列化对象时，Jackson未显式指定字符集，响应头Content-Type缺失charset=utf-8。
解决：在application.yml中强制设置Jackson字符集，并配置Tomcat URI编码。

spring: http: encoding: charset: UTF-8 force: true mvc: pathmatch: matching-strategy: ant_path_matcher # Spring Boot 2.7兼容旧版路径匹配 server: tomcat: uri-encoding: UTF-8

4.2 现象：MyBatis-Plus的page()分页查询，total总数为0，但records列表有数据

原因：PageHelper与MyBatis-Plus分页插件冲突。若项目曾引入pagehelper-spring-boot-starter，其PageInterceptor会劫持SQL，导致MP的PaginationInnerInterceptor失效。
解决：彻底删除pagehelper相关依赖，确认pom.xml中只有mybatis-plus-boot-starter。检查application.yml中无pagehelper:配置段。

4.3 现象：@Transactional方法内调用本类另一个@Transactional方法，事务不生效

原因：Spring事务基于代理（AOP），本类方法调用是this引用，绕过了代理对象，事务注解被忽略。这是Java面试八股文，但90%的初学者在写MemberService.renewMembership()调用StorageRecordService.save()时会栽。
解决：将被调用方法抽离到独立Service，或通过ApplicationContext获取代理对象调用：

@Service public class MemberService { @Autowired private ApplicationContext context; public void renew() { // 通过上下文获取代理对象，确保事务生效 StorageRecordService service = context.getBean(StorageRecordService.class); service.save(record); } }

4.4 现象：MySQL 8.0.33执行INSERT INTO t_member (...) VALUES (...)报错Field 'create_time' doesn't have a default value

原因：MySQL 8.0严格模式（STRICT_TRANS_TABLES）开启，而create_time字段定义为NOT NULL但无DEFAULT CURRENT_TIMESTAMP。MyBatis-Plus的@TableField(fill = FieldFill.INSERT)未生效，因为fill策略需配合MetaObjectHandler实现。
解决：在实体类Member.java中为createTime字段加注解，并实现MetaObjectHandler：

@TableField(fill = FieldFill.INSERT) private LocalDateTime createTime; // 新建处理器类 @Component public class MyMetaObjectHandler implements MetaObjectHandler { @Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, "createTime", LocalDateTime.class, LocalDateTime.now()); } }

4.5 现象：ReservationService.createReservation()在高并发下，count()查不到重叠记录，但save()仍因唯一索引失败

原因：count()和save()之间存在微小时间窗口（纳秒级），另一线程在此间隙插入成功。这不是Bug，是设计使然——应用层校验用于提升体验，唯一索引才是数据底线。
解决：接受此现象，将catch (DuplicateKeyException)中的提示改为用户可理解的语言（见3.2节代码），不要试图用synchronized锁住整个方法——那会把系统变成单线程，吞吐量归零。

4.6 现象：MemberMapper.selectList()返回空列表，但MySQL客户端执行相同SQL能查出数据

原因：实体类Member.java中字段名与数据库列名不一致，且map-underscore-to-camel-case: true未生效。常见于字段名为member_name，但实体属性写成membername（少下划线）或memberName（驼峰正确但配置未开）。
解决：检查application.yml中mybatis-plus.configuration.map-underscore-to-camel-case: true是否拼写正确（注意是configuration下，不是global-config）；用@TableField("member_name")显式标注可疑字段。

4.7 现象：项目启动时报java.lang.ClassNotFoundException: javax.servlet.Filter

原因：Spring Boot 2.7使用Servlet API 4.0，而javax.*包在Jakarta EE 9中已迁移至jakarta.servlet.*。若依赖了老版本spring-boot-starter-tomcat或手动引入了javax.servlet-api，就会冲突。
解决：确保pom.xml中只存在Spring Boot官方starter，删除所有javax.servlet相关依赖。检查Maven依赖树：mvn dependency:tree | grep servlet，确认输出中只有org.apache.tomcat.embed:tomcat-embed-core及其jakarta.*包。

5. 进阶验证：用Postman+MySQL命令行交叉验证业务逻辑的每一处毛刺

写完代码不验证，等于没写。很多开发者卡在“功能似乎能跑，但不敢上线”，根源在于验证方式太粗糙——只点前端按钮看页面，不碰数据底层。真正的验证必须三线并行：Postman测API契约、MySQL命令行查数据终态、日志文件看执行路径。下面以“私教课时冻结”这个易错点为例，演示如何用最小成本建立可信验证链。

5.1 定义验证目标：冻结课时后，会员不可约新课，但已约课程不受影响

业务规则很清晰，但实现常出错：1）冻结操作只改了coach_status字段，忘了同步更新member表的关联状态；2）冻结后Reservation查询未过滤coach_status = 'frozen'，导致会员仍能看到可约课表；3）冻结期间产生的消费记录未标记来源为“冻结期”，导致财务对账混乱。验证必须覆盖这三点。

5.2 Postman构造四步验证链：从状态变更到结果反馈

用Postman依次发送四个请求，形成闭环。每个请求的Body和Expected Response必须明确写死，避免主观判断。

关键技巧：在Postman的Tests标签页里写JS断言，自动校验响应。例如步骤3的Tests：

pm.test("Coach status is frozen", function () { var jsonData = pm.response.json(); pm.expect(jsonData.status).to.eql("frozen"); });

5.3 MySQL命令行执行三道终态快照：用SQL证明逻辑落地

Postman只验证API，数据是否真改对，必须下SQL。在MySQL客户端执行以下三条命令，它们是“法律证据”：

-- 1. 证明教练状态已变（冻结操作生效） SELECT id, status, freeze_reason FROM t_coach WHERE id = 1; -- 2. 证明历史预约未被删除（已约课程保留） SELECT COUNT(*) FROM t_reservation WHERE coach_id = 1 AND status = 'confirmed'; -- 3. 证明新预约被拦截（无新增记录） SELECT COUNT(*) FROM t_reservation WHERE coach_id = 1 AND start_time >= '2024-06-01 00:00:00' AND create_time > NOW() - INTERVAL 1 HOUR; -- 若返回0，说明拦截成功；若>0，说明第4步Postman测试失败或代码有bug

5.4 日志文件追踪执行路径：定位“为什么没进if分支”

当Postman返回400但预期是200，或MySQL查不到数据时，光看代码容易陷入“我以为我写了”。此时打开logs/spring.log（需在application.yml中配置logging.file.name: logs/spring.log），搜索关键词：

# 查找冻结操作的完整执行栈 2024-05-20 14:22:33.123 DEBUG 12345 --- [nio-8080-exec-2] c.e.f.s.c.CoachController : [freezeCoach] Enter with coachId=1 2024-05-20 14:22:33.125 DEBUG 12345 --- [nio-8080-exec-2] c.e.f.s.s.CoachService : [freezeCoach] Start updating coach status... 2024-05-20 14:22:33.128 DEBUG 12345 --- [nio-8080-exec-2] c.e.f.s.s.CoachService : [freezeCoach] Update SQL: UPDATE t_coach SET status=?, freeze_reason=?, update_time=? WHERE id=?

如果日志里没有Enter with coachId=1，说明请求根本没进Controller——检查@PostMapping("/freeze")路径是否与Postman URL完全一致（大小写、斜杠）；如果有Enter但没有Start updating，说明@Valid校验失败，日志会打印BindingResult错误。

我坚持一个习惯：每次提交代码前，必跑一遍这四步验证链（Postman四请求+MySQL三查+日志扫一眼）。不是为了“显得专业”，而是因为在健身系统里，一个状态位的错误，意味着会员付了钱却上不了课，或者私教白等一小时——这种损失，没法用单元测试覆盖率数字来弥补。希望帮到你。

本文还有配套的精品资源，点击获取