简介：一套基于 Java SSM 框架的健身房管理系统设计与实现资料，面向进行毕业设计、课程设计或 Java Web 项目实战的开发者。系统采用管理员与会员双角色架构，管理员端涵盖会员卡信息管理、会员缴费、课程与教练信息维护、私教课程报名管理、上课记录登记，以及缴费和上课数据的查询统计；会员端支持个人信息修改、会员卡与到期时间查看、私教课程预约、历史缴费与上课记录查询，并可在线提交意见反馈。整体业务覆盖健身房日常运营场景，数据库选用 MySQL，代码基于 Spring、Spring MVC、MyBatis 分层组织，能够清晰呈现权限区分、事务处理与持久层操作的设计思路。压缩包整体约 21.61MB，可直接对照学习项目结构、模块调用关系与数据库脚本，适合作为管理类系统设计与论文撰写的参考案例。当前已有 75 人学习，通过该项目可掌握 SSM 整合配置、常见业务统计查询以及前后台功能模块的划分方法。

1. 基于 Java SSM 的健身房管理系统：先看清这套课设源码能解决什么

做毕业设计技术复核这些年，我接触过不少基于 Java SSM 的课设项目，健身房管理系统是其中需求最完整、最能讲清业务闭环的一类。它不只是简单的增删改查堆料——会员办理、私教课程报名、上课记录登记、缴费统计、意见反馈回复，管理员和会员两端的功能边界划得很清楚，覆盖了「从办卡到消耗完最后一节私教课」的完整链路。适合两类人：一是 Java 后端刚入门、想拿 SSM 整合练手的学生，拿它当课设底子正合适；二是想快速搭一套内部管理系统雏形、之后做二次开发的从业者，代码结构规范，改起来不费劲。这篇笔记我会从表结构设计讲到核心业务逻辑，再到部署验证和二次开发，把我复现时踩过的坑一并写出来。源码本身不复杂，但照着跑一遍，你对 SSM 的分层逻辑和 MyBatis 的 SQL 控制力会明显上一个台阶。

2. SSM 项目骨架：包结构、九张表与三份 XML 的职责边界

拿到一套 SSM 源码，我习惯先不看业务代码，而是先看三样东西：包结构、建表脚本、配置文件。这三样能告诉你这个项目的边界在哪、能改到什么程度、哪些地方是写死的。健身房管理系统用的就是标准的 SSM 三层结构，Spring 管对象、SpringMVC 管请求、MyBatis 管 SQL，各管一段。

2.1 三层包结构：Controller、Service、Mapper 各自管什么

先看一个典型的包结构，这套健身房项目基本就是下面这个样子：

com.gym ├── controller # 前后端交互层，接收请求、返回结果 ├── service # 业务接口 │ └── impl # 业务实现 ├── mapper # MyBatis 接口 + XML 映射 ├── entity # 实体类，与表字段一一对应 ├── vo # 视图对象，给前端用的封装 └── common # 统一返回结果、工具类

这里的核心规则是：controller 里不写 SQL，mapper 里不写业务判断，service 才是业务逻辑真正落地的地方。很多课设代码翻车就翻在把校验逻辑全堆在 controller 里，页面一调接口，绕过 controller 直接调 service，校验就失效了。

实体类这块，注意字段命名直接使用驼峰，方便和数据库下划线字段做映射。会员表对应的实体大概是这样的：

public class Member { private Integer id; private String username; private String password; private String name; private String phone; private String gender; private Date createTime; // getter / setter 省略 }

说明：实体类字段名与数据库列名（member 表的 username、phone、create_time 等）保持一一对应，配合 MyBatis 的驼峰映射开关，查询结果能自动填充，不需要为每个字段手写 resultMap。密码字段我建议用 varchar 存加密后的值，课设里直接存明文的问题后面避坑章节会专门讲。

2.2 数据库设计：九张表把办卡到缴费串起来

这套系统的数据库设计是 MySQL，核心表我整理了一下，总共九张。先看建表脚本，再看设计理由。

-- 管理员表 CREATE TABLE admin_user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL ); -- 会员表 CREATE TABLE member ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, name VARCHAR(30), phone VARCHAR(20), gender CHAR(2), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 会员卡表 CREATE TABLE member_card ( id INT AUTO_INCREMENT PRIMARY KEY, member_id INT NOT NULL, card_type VARCHAR(20) COMMENT '月卡/季卡/年卡', start_date DATE, end_date DATE, status TINYINT DEFAULT 1 COMMENT '1有效 0停用', FOREIGN KEY (member_id) REFERENCES member(id) ); -- 课程表 CREATE TABLE course ( id INT AUTO_INCREMENT PRIMARY KEY, course_name VARCHAR(50), description VARCHAR(255), price DECIMAL(10,2), duration INT COMMENT '课时数' ); -- 教练表 CREATE TABLE coach ( id INT AUTO_INCREMENT PRIMARY KEY, coach_name VARCHAR(30), specialty VARCHAR(50), phone VARCHAR(20), intro VARCHAR(255) ); -- 排课表 CREATE TABLE schedule ( id INT AUTO_INCREMENT PRIMARY KEY, course_id INT NOT NULL, coach_id INT NOT NULL, class_date DATE, start_time TIME, capacity INT DEFAULT 10 COMMENT '名额上限', booked_count INT DEFAULT 0 COMMENT '已报名人数' ); -- 预约报名表 CREATE TABLE booking ( id INT AUTO_INCREMENT PRIMARY KEY, member_id INT NOT NULL, schedule_id INT NOT NULL, booking_time DATETIME DEFAULT CURRENT_TIMESTAMP, status TINYINT DEFAULT 1, UNIQUE KEY uk_member_schedule (member_id, schedule_id) ); -- 缴费记录表 CREATE TABLE payment ( id INT AUTO_INCREMENT PRIMARY KEY, member_id INT NOT NULL, amount DECIMAL(10,2), pay_type VARCHAR(20) COMMENT '办卡/续卡/私教课', biz_id INT COMMENT '关联业务id', pay_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 上课记录表 CREATE TABLE attendance ( id INT AUTO_INCREMENT PRIMARY KEY, member_id INT NOT NULL, schedule_id INT NOT NULL, course_id INT, coach_id INT, record_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 意见反馈表 CREATE TABLE feedback ( id INT AUTO_INCREMENT PRIMARY KEY, member_id INT NOT NULL, content VARCHAR(500), reply VARCHAR(500), create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

表结构里几个关键取舍说一下。第一个是 booking 表的唯一索引 uk_member_schedule，这是防重复报名的最后一道锁，靠代码判重永远有并发窗口，数据库唯一键能直接挡住第二次插入。第二个是 payment 表用 biz_id 而不是外键指向具体业务表，因为一次缴费可能对应办卡、续卡、私教课三种业务，用 biz_id 加 pay_type 的组合更灵活，查询统计时也方便。第三个是 schedule 表冗余了 booked_count 字段，报名成功后用booked_count = booked_count + 1的原子更新来扣名额，而不是每次查 count 再判断，这样能避免超卖，这个细节在第三章会展开。

2.3 三份 XML 的职责边界：数据源、Mapper 扫描、MVC 视图

SSM 整合项目里 XML 配置容易让人犯晕，其实就三份，职责分得很干净。第一份是 spring-mybatis.xml，管数据源和 MyBatis 的整合：

<!-- 数据源配置 --> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName" value="com.mysql.cj.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/gym_db?serverTimezone=Asia/Shanghai&amp;characterEncoding=utf8"/> <property name="username" value="root"/> <property name="password" value="你的密码"/> </bean> <!-- SqlSessionFactory：MyBatis 的核心工厂 --> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="configuration"> <bean class="org.apache.ibatis.session.Configuration"> <property name="mapUnderscoreToCamelCase" value="true"/> <property name="logImpl" value="org.apache.ibatis.logging.stdout.StdOutImpl"/> </bean> </property> </bean>

参数这块我说几个重点。driverClassName 如果数据库是 MySQL 8.0 以上，必须用com.mysql.cj.jdbc.Driver，老项目里写com.mysql.jdbc.Driver的在新版本连接器下直接抛 ClassNotFoundException。url 里serverTimezone=Asia/Shanghai必须带，否则 MySQL 8 会报时区错误。characterEncoding=utf8解决中文写入乱码。mapUnderscoreToCamelCase 打开后，create_time才能自动映射到createTime，这是后面所有查询不写 resultMap 的前提。开 StdOutImpl 日志能在控制台直接看到每次执行的 SQL，排错非常有用。

第二份是 springmvc.xml，只关心请求路由和视图解析：

<mvc:annotation-driven/> <context:component-scan base-package="com.gym.controller"/> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean> <mvc:default-servlet-handler/>

第三份是 web.xml，把 DispatcherServlet 挂到 Tomcat 上，配置load-on-startup和 Spring 配置文件的加载路径。这三份配置只要有一处路径对不上，启动时要么报 ClassNotFound，要么报 Mapper 找不到，后面避坑章节会专门列出排查顺序。

2.4 ssm常用注解：贴对了少走一半弯路

SSM 项目的注解使用有一套约定俗成的套路，面试也常考。这里把最常见的几个列一下，顺便说说它们各自管什么。

这里最常踩的坑是 @Transactional 失效。Spring 的事务是基于 AOP 代理的，同类内部方法直接调用this.xxx()时不会走代理，事务就不生效。比如在开门禁的服务类里，一个方法调用同类另一个加 @Transactional 的方法，后者是控制不了事务的。解决方法是把需要事务的方法拆到不同 Bean 里，或者通过注入自身代理调用来绕过。

3. 会员端核心逻辑：办卡、报名、查记录三块代码怎么落地

会员端的业务看起来简单，实际上有三个环节最容易出问题：会员卡到期时间的计算、私教课报名时的重复与超卖、查询列表的分页。这一章我一步步拆开讲。

3.1 会员卡办理：到期时间计算与缴费记录同事务写入

办卡不只是往 member_card 里插一条数据，它连着两件事：根据卡类型算出到期日，以及同步生成一条缴费记录。这两件事必须在一个事务里完成，否则会出现卡办了但钱没记上，或者钱记了但卡无效的脏数据。

@Service public class MemberCardServiceImpl implements IMemberCardService { @Autowired private MemberCardMapper memberCardMapper; @Autowired private PaymentMapper paymentMapper; @Transactional public void openCard(MemberCard card, Integer memberId) { card.setMemberId(memberId); card.setStartDate(new Date()); // 按卡类型累加：月卡+1月，季卡+3月，年卡+12月 Calendar cal = Calendar.getInstance(); cal.setTime(new Date()); switch (card.getCardType()) { case "月卡": cal.add(Calendar.MONTH, 1); break; case "季卡": cal.add(Calendar.MONTH, 3); break; case "年卡": cal.add(Calendar.YEAR, 1); break; default: throw new RuntimeException("未知卡类型"); } card.setEndDate(cal.getTime()); memberCardMapper.insert(card); Payment payment = new Payment(); payment.setMemberId(memberId); payment.setAmount(card.getPrice()); payment.setPayType("办卡"); payment.setBizId(card.getId()); paymentMapper.insert(payment); } }

逻辑说明：核心是 Calendar 的 add 方法按月累加，不用手动处理跨月跨年的进位问题。card.getId() 在 MyBatis 插入后会通过 useGeneratedKeys 回填，所以插入完 card 再取 id 是安全的。payment 的 biz_id 关联的就是这张卡的 id，后续对账能查到每一笔钱的来路。@Transactional 保证两次 insert 要么都成功要么都回滚，这一步是这个方法最重要的兜底。

参数说明：卡类型是写死的字符串，课设里可以接受，实际项目中建议用字典表或者枚举，避免「月卡」「月卡 " 这种带空格的值导致计算错误。price 属于哪张表？注意 member_card 表里我设计时没放 price 字段，实际项目里要么在卡表冗余一份 price，要么从课程/套餐表带出，否则 payment 的 amount 没来源。这是一个容易忽略的设计漏洞。

3.2 私教课报名：三重校验与原子扣减名额

报名私教课是这套系统里并发风险最高的接口。多个会员同时抢同一节私教课，如果逻辑是先查名额再判断再扣减，理论上会超卖。我一般会做三重校验：会员卡有效性、是否已报名、名额是否足够。

@Transactional public boolean bookCourse(Integer memberId, Integer scheduleId) { // 1. 排课是否存在 Schedule schedule = scheduleMapper.selectById(scheduleId); if (schedule == null) { throw new RuntimeException("排课不存在"); } // 2. 会员卡是否有效且在有效期内 MemberCard card = memberCardMapper.selectValidByMemberId(memberId); if (card == null || card.getEndDate().before(new Date())) { throw new RuntimeException("会员卡已过期，无法报名"); } // 3. 是否已报名（数据库唯一键做最终兜底） Booking exist = bookingMapper.selectByMemberAndSchedule(memberId, scheduleId); if (exist != null) { throw new RuntimeException("请勿重复报名"); } // 4. 名额校验 if (schedule.getBookedCount() >= schedule.getCapacity()) { throw new RuntimeException("该时段名额已满"); } // 5. 写入预约记录 bookingMapper.insert(memberId, scheduleId); // 6. 原子扣减剩余名额 scheduleMapper.increaseBookedCount(scheduleId); return true; }

对应的 Mapper SQL 是关键，扣减名额时必须用原子更新，不能先查再改：

<update id="increaseBookedCount" parameterType="int"> UPDATE schedule SET booked_count = booked_count + 1 WHERE id = #{scheduleId} AND booked_count < capacity </update>

逻辑说明：increaseBookedCount 里的AND booked_count < capacity是 SQL 层的最后一道关卡，即使 Java 层判断被并发穿透，数据库条件不满足时更新影响行数为 0，事务回滚，预约记录也跟着消失。配合 booking 表的唯一索引，重复报名同样会被数据库拦下。这三层校验下来，课设答辩时面试官问并发场景，你可以直接把这个设计讲清楚。

参数说明：update 返回 int 是受影响行数，service 里可以根据返回值判断是否真的扣减成功，扣减失败时抛异常让事务整体回滚，而不是继续往下执行。排课表的 capacity 和 booked_count 都是 int，实际项目中名额多时要考虑用什么粒度锁排课记录，这里用条件更新的乐观锁方案成本最低。

3.3 会员查记录：上课记录与缴费明细的分页查询

会员端的查询需求很朴素：看自己上过哪些课、交过哪些钱、卡什么时候到期。这类查询最大的问题是一股脑把全表数据返给前端。毕业设计答辩时这算一个明显的扣分点，用 PageHelper 做分页是 SSM 项目里的标准做法。

@Service public class AttendanceServiceImpl implements IAttendanceService { @Autowired private AttendanceMapper attendanceMapper; @Override public PageInfo<Attendance> pageMyAttendance(Integer memberId, int pageNum, int pageSize) { // 分页插件只对紧接着的一条查询生效 PageHelper.startPage(pageNum, pageSize); List<Attendance> list = attendanceMapper.selectByMemberId(memberId); return new PageInfo<>(list); } }

Controller 层配合 Session 里存的登录会员来查询：

@RestController @RequestMapping("/member") public class MemberController { @Autowired private IAttendanceService attendanceService; @Autowired private IPaymentService paymentService; @RequestMapping("/myAttendance") public Result myAttendance(HttpSession session, @RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "10") Integer pageSize) { Member loginMember = (Member) session.getAttribute("loginMember"); if (loginMember == null) { return Result.error("未登录"); } return Result.success(attendanceService.pageMyAttendance(loginMember.getId(), pageNum, pageSize)); } }

逻辑说明：PageHelper.startPage 的原理是拦截下一条执行的 SQL，自动拼上 limit 子句，所以 startPage 和 mapper 查询之间不能插入其他查询语句，否则分页会对错对象。PageInfo 里带了 total、pageNum、pageSize、list 等现成结构，前端直接拿来渲染就行。membership 卡到期提醒也是同一个套路，查 member_card 的 end_date 对比当前日期，快到期时给会员端页面点亮一个提示条。

参数说明：pageNum 从 1 开始，pageSize 建议限制在 50 以内，避免一次拉太多。Session 存会员对象时别把 password 也塞进去，稳妥做法是查询时直接排除该字段，或者用 VO 对象只带必要字段。这个项目里会员端就是靠 Session 判断登录态，接口层面没有做更细的权限控制，实际项目中需要配合拦截器校验角色。

4. 管理员端功能实现：课程管理、上课登记与统计 SQL 这样写

管理员端比会员端多两类东西：一类是课程、教练这些基础资料的维护，一类是缴费、上课记录的统计查询。统计查询是这套系统里 SQL 难度最高的地方，也是答辩时最能讲出东西的模块。

4.1 课程与教练管理：CRUD 之外的删除保护

课程和教练的增删改查本身不复杂，每张表一套 Controller、Service、Mapper 的套路。真正容易翻车的是删除操作——课程被排课引用了还允许删，数据直接变成孤儿记录。

@Service public class CourseServiceImpl implements ICourseService { @Autowired private CourseMapper courseMapper; @Autowired private ScheduleMapper scheduleMapper; @Override public void deleteCourse(Integer courseId) { // 删除前检查排课引用 int cnt = scheduleMapper.countByCourseId(courseId); if (cnt > 0) { throw new RuntimeException("该课程已有排课记录，不能直接删除"); } // 进一步检查上课记录，防止历史数据被破坏 int attendanceCnt = attendanceMapper.countByCourseId(courseId); if (attendanceCnt > 0) { throw new RuntimeException("该课程已有上课记录，建议停用而非删除"); } courseMapper.deleteById(courseId); } }

逻辑说明：这里讲了一个课设里少见的处理思路——删除前先检查引用，存在引用时抛业务异常而不是执行 delete。教练表的删除同理，教练名下还有排课时不能删，要么提示先清排课，要么把删除改为下架（加 status 字段改成 0）。这两种方案我推荐后者，数据留痕比物理删除更稳妥，尤其涉及上课记录和缴费历史，删了就没法对账了。

参数说明：countByCourseId 返回 int，0 表示无引用。实际项目里引用检查涉及多张表时，建议把检查逻辑抽成一个私有方法，别在 controller 里写这些判断。更新操作同理，update 的 SQL 要注意别把 create_time 这类字段一起覆盖掉，一般只 update 前端传过来的字段。

4.2 排课与上课记录：名额释放与打卡登记

排课是管理员给课程安排教练和时间，上课记录则是会员上完课后管理员来登记。这两件事的联动比较容易漏：会员报名后被管理员删除排课，预约记录和名额要一起处理。

@Transactional public void cancelSchedule(Integer scheduleId) { // 1. 查出该排课下所有预约 List<Booking> bookings = bookingMapper.selectByScheduleId(scheduleId); // 2. 删除预约记录 bookingMapper.deleteByScheduleId(scheduleId); // 3. 重置已报名人数（注意是重置为0，不是减去1） scheduleMapper.resetBookedCount(scheduleId); // 4. 删除排课记录本身 scheduleMapper.deleteById(scheduleId); }

逻辑说明：排课取消是一个复合操作，涉及预约表、排课表两张表的联动，必须放在同一个事务里。重置 booked_count 为 0 而不是逐个递减，是因为预约已经全删了，逐个减容易出现中间状态错误。如果只想取消某个会员的报名，则走单条删除逻辑，booked_count 用booked_count - 1并加booked_count > 0条件保护。

上课记录的登记，管理员端是单个添加，会员端是列表查看。登记时我习惯冗余一份 course_id 和 coach_id 到 attendance 表，这样查询上课记录时不用反复 join 排课表，列表页性能好很多，课设数据量下无所谓，但可以把这种冗余设计思路写进答辩稿里。

4.3 缴费统计与上课统计：聚合 SQL 的口径问题

统计功能是管理员端最有含金量的部分：按课程维度统计报名人数和收入，按会员维度统计消费次数。先看一段按课程统计的 SQL：

SELECT c.id, c.course_name, COUNT(DISTINCT b.member_id) AS join_count, COALESCE(SUM(p.amount), 0) AS total_amount FROM course c LEFT JOIN schedule s ON s.course_id = c.id LEFT JOIN booking b ON b.schedule_id = s.id LEFT JOIN payment p ON p.biz_id = c.id AND p.pay_type = '私教课' GROUP BY c.id, c.course_name ORDER BY total_amount DESC;

逻辑说明：这段 SQL 的逻辑是「课程 → 排课 → 预约 → 缴费」四级 LEFT JOIN，COUNT(DISTINCT member_id) 统计报名人数是为了避免会员报名多节课被重复计数，COALESCE 把没有收入的课程金额补成 0，防止前端显示 null。统计口径上要注意：报名人数和实际上课人数是两个口径，如果只统计了 booking 里的人数，实际到课率就没有体现，答辩时可以把这两个口径对比讲，说明系统为什么还需要 attendance 表。

参数说明：pay_type = '私教课' 的条件是为了让 payment 表里的金额只统计私教课收入，办卡收入是另一笔，统计时不要混在一起。按时间维度统计就再加一个WHERE p.pay_time BETWEEN ? AND ?。这种聚合 SQL 是 SSM 项目里最能在面试中展示 SQL 能力的素材，建议把 GROUP BY、LEFT JOIN、COALESCE 这几个点都吃透。

意见反馈的回复逻辑相对简单，做个防重复回复的判断就行：查出来 reply 字段不为空就提示已回复，否则写入回复内容。这里注意反馈表和回复字段分开存，方便前端同时展示原反馈和回复内容。管理员端的课程、教练、缴费、上课记录四个模块，覆盖了「基础数据维护 + 业务数据登记 + 统计查询」三类操作，把这四条链路走通，这套系统的主体功能就算掌握了。

5. 避坑指南：SSM 项目复现时会踩的五个高频坑

这一章全部来自我实际复现 SSM 课设源码的血泪经验。下面五条按出现频率排序，每一条都按「现象 → 原因 → 解决」写，建议对照你的环境逐条排查。

5.1 现象：项目启动直接报数据库连接错误

现象：Tomcat 启动时抛ClassNotFoundException: com.mysql.jdbc.Driver或者The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。

原因：这类报错 90% 是两件事——第一，JDK 和 MySQL 版本对不上，MySQL 8.0 的驱动类名已经改成com.mysql.cj.jdbc.Driver，老配置里还是旧类名；第二，连接串里没带serverTimezone参数，MySQL 8 驱动默认会去读系统时区，读不到就报错。

解决：驱动类名换成com.mysql.cj.jdbc.Driver，url 里补上?serverTimezone=Asia/Shanghai&characterEncoding=utf8。如果项目还在用 mysql-connector-java 5.x，建议直接升级到 8.0.x，JDK 8 环境完全兼容。

5.2 现象：数据库查询全部返回 null，字段明明有值

现象：列表页面能查到记录条数，但每个字段都是 null，控制台打出的 SQL 也正确。

原因：MyBatis 的默认映射是「列名 = 属性名」的严格匹配，数据库的create_time对应不到 Java 的createTime，中间差了下划线。这是 SSM 项目最高频的翻车点，没有之一。

解决：在 SqlSessionFactoryBean 的 configuration 里打开驼峰映射开关：

<property name="mapUnderscoreToCamelCase" value="true"/>

顺手在 mybatis 配置文件里把logImpl设为 StdOutImpl，日志能看到 SQL 就能快速定位是哪条查询出了问题。如果旧项目用了大量 resultMap，开关不一定全部覆盖，还是要逐条看结果。

5.3 现象：插入中文数据变成问号

现象：页面表单提交中文，MySQL 里存的是???，或者查询回来是乱码。

原因：三个环节至少有一个编码不对。常见的是数据库表默认字符集不是 utf8，或者连接串没带characterEncoding=utf8。有时候页面本身是 GBK 编码，和项目里强制 utf8 冲突，也会出现乱码。

解决：建库时显式指定字符集，连接串补上编码参数，这两步能解决绝大多数情况。如果还乱，去检查 Tomcat 的 URIEncoding，在 server.xml 的 Connector 上加URIEncoding="UTF-8"。注意乱码问题最佳治疗手段是开头就统一，建表脚本里所有表都带DEFAULT CHARSET=utf8mb4，别默认用 MySQL 的 latin1。

5.4 现象：启动时报 NoSuchMethodError 或 ClassNotFoundException（spring 相关类）

现象：Tomcat 启动时抛java.lang.NoSuchMethodError: org.springframework.util.StringUtils.hasText或者ClassNotFoundException，代码本身看着没问题。

原因：Maven 依赖版本冲突。pom.xml 里 spring-webmvc、spring-context、spring-jdbc 版本不一致，或者同一个 jar 在依赖树里出现多个版本。SSM 项目最常见的是 spring 全家桶版本对不齐，加上 jackson 老版本和 spring 5 的兼容问题。

解决：所有 spring 相关依赖统一版本号，用 property 管理版本：

<properties> <spring.version>5.3.24</spring.version> </properties> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>${spring.version}</version> </dependency>

然后执行mvn dependency:tree看依赖树，把重复的旧版本用 exclusion 排除。我一般会直接复制这套 pom 的骨架版本组合：Spring 5.3.x + MyBatis 3.5.x + mybatis-spring 2.0.x + mysql-connector-java 8.0.x + jackson-databind 2.13.x，这个组合在 JDK 8 上非常稳。

5.5 现象：页面 404，接口 406，静态资源全挂

现象：首页能打开，但访问某个 controller 路径 404；或者 Ajax 请求返回 406 Not Acceptable；或者 js、css 加载不出来。

原因：404 一般是 DispatcherServlet 的 url-pattern 配置问题，配成/时静态资源被拦截，需要 mvc:default-servlet-handler 放行；406 一般是 Jackson 没正确序列化，controller 返回对象但 springmvc.xml 里mvc:annotation-driven没配好，导致找不到能处理 JSON 的转换器。

解决：406 的修复是把 springmvc.xml 里的mvc:annotation-driven配好，确认 jackson-databind 在 pom 里且版本兼容；404 的修复是确认 controller 的 @RequestMapping 路径和前端请求路径完全一致，别忽略大小写和末尾斜杠。静态资源问题统一用mvc:default-servlet-handler兜底，这是 SSM 项目里最省事的方案。

这套避坑顺序建议刻在脑子里：先数据库连接，再 MyBatis 映射，再编码，再依赖，最后才是 springmvc 路由。百分之八十的启动失败都能在这五条里找到答案。

6. 部署验证与二次开发：跑通闭环后再加一个体测模块

源码拿到手，先别急着看代码，按流程把环境跑通才是正经事。我的习惯步骤是：建库 → 建表 → 部署 → 按业务闭环走查 → 记录边界行为。走完这套流程，你对这套代码的理解深度和单纯读代码完全不一样。

6.1 部署五步走

# 1. 建库（假设 MySQL 已启动） mysql -uroot -p -e "CREATE DATABASE gym_db DEFAULT CHARACTER SET utf8mb4;" # 2. 导入建表脚本 mysql -uroot -p gym_db < gym_db.sql # 3. 确认 JDK 环境变量已配置，版本信息正常 java -version # 4. 使用 Maven 打包（跳测试，避免单元测试卡住） mvn clean package -DskipTests # 5. 将 war 包丢进 Tomcat webapps 目录，启动 Tomcat cp target/gym.war $TOMCAT_HOME/webapps/ $TOMCAT_HOME/bin/startup.sh

这几步里最容易卡的是 JDK 版本和 Tomcat 版本不匹配。课设源码一般按 JDK 8 编写，如果你机器上是更高版本的 JDK，建议先装一个 JDK 8 并切换环境变量，别在版本问题上消耗时间。

6.2 按业务闭环走一遍验证清单

走查时重点关注两件事：一是跨角色操作是否会越权，比如会员端直接访问管理员接口能不能拿到敏感数据；二是非法操作是否有提示，比如过期会员报名私教课。这些边界行为在答辩场上都是加分项。

6.3 二次开发示例：加一个体测记录功能

如果你要做二次开发，套路非常固定：建表 → 建实体 → 建 Mapper → 建 Service → 建 Controller → 加页面。以体测记录为例，核心就是新增一张 body_test 表，字段包含 member_id、height、weight、test_date，然后照抄 attendance 的查询链路把页面和接口接上。注意新表要复用已有的 Result 统一返回、复用 Session 拿会员 id，别自己再造一套返回结构。这样加功能，半小时就能把一个完整模块装进这套系统里。

还有一件重要的事：改代码之前，先把原始建表脚本和原始 pom.xml 单独备份一份。这套源码在资源平台能直接搜到，下载后先跑通再动手改。我那会儿急着改需求，把表结构改了一半才发现方向错了，想回退已经来不及，只能重新导库。从那以后我每次拿到 SSM 课设源码，都会先建一个干净的库完整跑一遍，再复制一份原始脚本留着当后悔药，改一个模块验证一个模块，绝不批量改动。这套基于 Java SSM 的健身房管理系统，功能完整度在课设项目里属于中上水平，把它吃透，你的 SSM 分层意识和 SQL 功底都会实打实地涨一截。希望帮到你。

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