这篇文章的核心价值在于不光是给你一套能跑的源码更重要的是把“为什么这么设计”讲清楚。我做过好几个类似的单体业务系统健身房管理系统属于典型的“中等复杂度管理类项目”——比纯CRUD多一点业务状态流转但又不像电商那样高并发。它对初学者和刚转Java后端的人非常友好技术栈经典、业务场景容易代入、可以完整走通从数据库设计到前后端联调的全流程。1. 项目整体设计与技术选型1.1 这套系统到底在解决什么问题先想清楚一个朴素的场景一家线下健身房每天要处理什么事情会员办卡、到期续费、约团操课、私教排期、刷卡进场、记录体测数据。这些事以前靠前台用Excel和纸质登记簿就可以但一旦店里有几千个会员、一天有十几节团课人工管理的出错率就会直线上升比如会员卡到期了还在用、约了课不来上也没人管、教练排班靠口头沟通经常撞车。所以这套系统的核心定位是解决小型健身房运营中的信息孤岛问题。它不是一个花哨的SaaS平台而是一个把会员、课程、教练、入场记录、续费提醒揉到一套系统里的单体应用。技术上选SpringBootVue数据库用MySQL持久层用MyBatis都是国内Java开发者最熟悉的组合也是面试里最高频问到的内容。1.2 技术选型的三个关键考量第一为什么用SpringBoot而不是SSH或者SpringMVC因为SpringBoot对初学者最大的价值是“约定优于配置”。你不需要写一堆XML配置去声明Bean一个启动类就能把Tomcat内嵌进来跑起来。这对健身房管理系统这种业务逻辑清晰、非分布式的场景足够用了。它内置的自动配置机制比如spring-boot-starter-web、spring-boot-starter-jdbc可以让你把精力放在业务代码而不是配置地狱里。第二为什么用MyBatis而不是JPA我的理由是SQL可控性。健身房管理系统里会有很多多表关联查询比如“查询某教练未来七天所有课程及已预约人数”“统计本月新增会员数”。MyBatis允许你手写SQL遇到复杂查询时可以精确控制JOIN逻辑和索引使用而JPA的Hibernate虽然自动生成SQL方便但遇到复杂统计时要么写JPQL要么搞Specification调试成本反而更高。第三为什么不用前后端分离之外的方案说实话我见过很多人把模板引擎Thymeleaf和服务端渲染方案也用在这类项目上。但是Vueaxios这套组合的价值在于你可以把页面交互做得更细腻——比如会员列表的实时搜索、课程日历的拖拽排期这些交互在服务端渲染的页面里实现成本极高。前端项目独立维护后端只提供JSON接口后来想加小程序端或者App端接口可以直接复用。技术选型清单组件选择说明后端框架SpringBoot 2.7.x稳定版本兼容性好社区资料多持久层MyBatis 3.5.x手写SQL灵活可控适合多表关联数据库MySQL 5.7 / 8.0InnoDB引擎事务支持完善前端Vue 2.6 Element UI组件生态成熟适合后台管理界面权限JWT 拦截器无状态认证适合前后端分离构建Maven npm常规标配提示SpringBoot版本不用追新。2.7.x是目前兼容性最好的版本踩坑资料最多。如果你用SpringBoot 3.xjavax包名变成了jakarta很多旧教程里的import javax.servlet会直接报错新手排查起来很痛苦。2. 数据库设计与核心表结构2.1 会员、课程、教练之间的表关系这是整个系统的基石表设计错了后面写代码要多写很多救火逻辑。我建议拆成六张核心表member会员、coach教练、course课程、course_schedule排课、booking_record预约记录、entry_log入场记录。外加一张user表用来做系统登录账号。会员和课程之间是多对多关系但直接建立一张中间表会少一个维度会员预约的不是“课程”而是“某一天某一时段的某节课程”。所以中间表要让booking_record关联到course_schedule而不是直接关联course。这一点非常关键——如果你把预约关系直接挂在课程上那同一节课不同时间的名额管理就会变成噩梦。2.2 关键字段设计与索引策略直接上我的建表重点逐条说明理由member表核心字段字段名类型说明idbigint主键自增card_novarchar(20)会员卡号要建唯一索引namevarchar(50)姓名phonevarchar(11)手机号membership_typetinyint1-月卡 2-季卡 3-年卡expire_datedate到期日期整点查询都靠它statustinyint1-正常 0-冻结这里有个值得抠的细节为什么会员卡号不直接用数据库自增id因为前台会员看到的卡号通常希望有业务含义比如GY20250101这种格式做成唯一索引的业务字段比直接用id更灵活。不过要注意卡号一旦定了就不要做更新主键的操作。course_schedule表最有设计感的字段是时间处理字段名类型说明idbigint主键course_idbigint关联课程coach_idbigint关联教练class_datedate上课日期start_timetime开始时间end_timetime结束时间max_peopleint人数上限booked_countint已预约人数statustinyint1-可约 2-已满 3-已取消为什么要把日期和时间拆成两个字段而不用datetime因为运营场景里会有“查看某教练周六所有课程”和“查看本周每天有哪些课在晚上7点开始”这两种查询拆开后你可以分别对class_date和coach_id建索引查询效率比在datetime列上做函数运算高一个量级。索引策略我实践下来的结论是card_no建唯一索引这是会员查询的最常用路径。course_schedule表给coach_id class_date建联合索引支撑教练排期查看。booking_record表给member_id和schedule_id分别建普通索引。不要在一张超过几万行的表上盲目建很多索引。这个系统最常用的是以上三条索引路径够用就行。你每多一个索引写入时都要多维护一棵B树。2.3 预约状态与并发控制预约功能是这套系统里最容易出bug的地方。两个会员同时抢同一节课的最后一个名额怎么保证不超卖第一层常规做法在booking_record表加唯一约束(member_id, schedule_id)保证一个会员对同一节课只能有一条预约记录。第二层需要靠事务和锁。我推荐在扣减名额时使用update course_schedule set booked_count booked_count 1 where id ? and booked_count max_people这条带条件的更新语句。MySQL的InnoDB引擎会在这条UPDATE执行时给命中行加排他锁后一个事务的UPDATE会阻塞直到前一个事务提交。这样从机制上杜绝了超卖。伪代码如下start transaction; update course_schedule set booked_count booked_count 1 where id #{scheduleId} and booked_count max_people; -- 影响行数为0说明已经没有名额直接回滚并提示 insert into booking_record(member_id, schedule_id, create_time) values(#{memberId}, #{scheduleId}, now()); commit;这个方案在单体应用和小并发场景下是完全够用的。如果你真的要做分布式部署再考虑Redis分布式锁或者乐观锁版本号但健身房管理系统的体量完全不需要。3. 后端SpringBoot核心模块实现3.1 分层结构与包组织直接用controller-service-mapper三层不要搞花活。com.example.gym ├── controller # 接口层只做参数接收和结果封装 ├── service # 业务逻辑层事务边界在这里 ├── mapper # MyBatis接口层 ├── entity # 数据库实体 ├── dto # 请求和响应对象 ├── config # 配置类拦截器、跨域等 ├── interceptor # JWT拦截器 └── util # 工具类JWT生成解析等为什么推荐controller直接调用serviceservice直接调用mapper不再加一层manager/bo因为这个系统的业务复杂度还没有到需要聚合服务的程度。层级太多反而导致一个接口的代码要改四五个文件项目维护成本比代码组织成本更高。等业务增长到需要多个service互相调用时再抽聚合层不迟。3.2 登录鉴权与角色权限系统分三种角色管理员、前台、教练。管理员管全部前台管会员和入场教练只管自己的排课和学员记录。我用的方案是登录成功发一个JWT前端把token存到localStorage每次请求在axios拦截器里把token加到请求头后端用拦截器统一校验。JWT的生成建议直接用io.jsonwebtoken库核心代码public String generateToken(Integer userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setExpiration(new Date(System.currentTimeMillis() 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }拦截器里只做两件事从Header拿token、解析并放行或者抛出401异常。public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { response.setStatus(401); return false; } try { Claims claims Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token.replace(Bearer , )).getBody(); request.setAttribute(userId, Integer.parseInt(claims.getSubject())); request.setAttribute(role, claims.get(role)); return true; } catch (Exception e) { response.setStatus(401); return false; } }这里有一个经验角色鉴权不要放在拦截器里做开关式判断而是让Controller里的方法自己判断角色。虽然拦截器也能做但一旦角色逻辑变复杂比如运营人员可以临时拥有前台权限拦截器里的规则会膨胀到不可维护。最简单可读的方式是定义自定义注解RequireRole用AOP切面统一处理但不要为了炫技一上来就上这套。先把拦截器按请求路径前缀做了基础放行角色判断在service层查一次当前用户角色就够。3.3 MyBatis动态SQL与业务查询健身房管理系统的查询条件非常多变比如会员管理页面有三个筛选项姓名、手机号、卡类型。你不可能为每种组合写一条独立SQL所以where和if标签就是核心工具。以会员列表查询为例select idsearchMembers resultTypecom.example.gym.entity.Member select * from member where if testname ! null and name ! and name like concat(%, #{name}, %) /if if testphone ! null and phone ! and phone like concat(%, #{phone}, %) /if if testmembershipType ! null and membership_type #{membershipType} /if /where order by create_time desc /selectwhere标签的价值在于它会自动处理第一个sand前置逗号问题。如果你手动写where 11风格差一些而且有SQL注入冗余判断。但是这里有一个坑必须提醒动态SQL一旦条件没传就变成了全表扫描。会员列表短时间内没问题但过万条记录后建议强制加上分页条件。分页方案我用的PageHelper引入依赖后用一套非常简洁PageHelper.startPage(pageNum, pageSize); ListMember list memberMapper.searchMembers(condition); PageInfoMember pageInfo new PageInfo(list);PageHelper的底层原理是拦截Executor在目标SQL执行前自动拼接LIMIT语句。用的时候有个细节PageHelper.startPage后面的第一条SELECT语句才会被分页拦截。如果你在查询前多执行了一次查询比如先查了一次其他表分页就会作用到错误的查询上这是很多人踩过的最典型的坑。3.4 事务控制与并发预约实现事务的默认边界是每个Mapper方法。但预约逻辑涉及两步扣减名额、插入预约记录。这两步必须在一个事务里否则会出现“扣了名额但是没插入记录”的诡异数据。我的做法是在Service层加上Transactional注解Override Transactional(rollbackFor Exception.class) public boolean bookCourse(BookingRequest request) { int affected courseScheduleMapper.increaseBookedCount( request.getScheduleId(), request.getMaxPeople()); if (affected 0) { throw new RuntimeException(没有可预约名额了); } bookingRecordMapper.insert(request.getMemberId(), request.getScheduleId()); return true; }rollbackFor Exception.class这一行非常关键。默认情况下Spring事务只回滚RuntimeException如果你把rollbackFor省略掉然后业务代码抛了SQLException这类受检异常事务是不会回滚的。这个细节在面试里也经常被问到。4. 前端Vue实现要点4.1 前端工程结构与路由拆分前端用的是Vue 2 Element UI Vue Router axios。管理系统的页面结构比较固定推荐拆成以下目录src ├── api # 每个模块的接口请求封装 ├── assets # 静态资源 ├── components # 公共组件会员表格、课程日历等 ├── router # 路由配置 ├── store # Vuex状态管理存用户信息和token ├── views # 页面组件按模块分文件夹 └── utils # 封装的axios实例路由配置我建议做后台管理界面的经典布局一个Layout组件包含顶部导航和侧边栏所有业务页面作为它的子路由{ path: /, component: Layout, redirect: /dashboard, children: [ { path: member, component: () import(/views/member/index.vue), meta: { title: 会员管理 } }, { path: course, component: () import(/views/course/index.vue), meta: { title: 课程管理 } }, { path: schedule, component: () import(/views/schedule/index.vue), meta: { title: 排课管理 } } ] }页面组件用动态import路由懒加载这个习惯要养成。不是因为这个项目需要而是以后项目大了懒加载可以显著减少首屏资源的体积。4.2 axios封装与Token处理axios不推荐直接在组件里写。我习惯封装成一个统一实例统一做超时配置、请求头注入和错误提示import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) // 请求拦截器自动携带token service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) // 响应拦截器统一处理错误 service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.msg || 请求失败) return Promise.reject(new Error(res.msg)) } return res }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } Message.error(error.message) return Promise.reject(error) } ) export default service这里有两个经验值得说。第一后端返回的统一结果集要有code、msg、data三个字段前端在响应拦截器里判断code 200再往下走。这样Controller里可以减少很多重复的判断代码。第二401处理非常关键。token过期后如果前端不做拦截每个接口都会弹一个奇怪的错误提示。在响应拦截器里统一跳转到登录页用户重新登录后跳回原页面这个体验才算合格。4.3 核心页面实现与交互细节会员管理页是一个典型的表格弹窗组合用Element UI的el-table和el-dialog。这里提醒一个新手必踩的坑表格数据更新后一定要重新调用接口拉最新数据不要在前端手动修改表格的data数组。手动改数据虽然界面看起来是马上变了但一旦刷新页面就会发现有数据不一致而且代码会变得难以维护。排课页的交互是整个系统的亮点推荐用日历视图展示某位教练未来七天的课程时间格。选中某个时间段后弹出预约详情弹窗显示当前已预约人数和剩余名额。这个页面的核心是把course_schedule列表按日期分组前端用date字段做分组的计算逻辑const groupedSchedules schedules.reduce((acc, item) { const date item.classDate if (!acc[date]) { acc[date] [] } acc[date].push(item) return acc }, {})这种分组计算的思路很朴素但配合Element UI的el-calendar可以快速搭出一个可用的排课视图。不要一上来就想着用复杂的第三方日历组件很多日历组件配置复杂还容易有样式兼容问题自己分组渲染最可控。5. 完整源码的部署与本地运行5.1 环境准备清单先列一个清单每一项都要过一遍工具版本建议用途JDK1.8或11运行SpringBootMaven3.6后端依赖管理Node.js14前端构建MySQL5.7或8.0数据库IDEIDEA或VS Code开发JDK版本建议不要太新JDK17或者21虽然也能跑但部分老版本的Maven插件在JDK17下有兼容问题新手排查时需要额外修改pom.xml的编译参数多出来的工作量完全没有必要。5.2 数据库初始化步骤项目源码里一般会带上一个sql/目录里面有建库脚本和初始化数据。我建议在自己环境里完整走一遍流程mysql -u root -p sql/init.sql登录MySQL后确认show databases; -- 看到名为 gym 的库说明建库成功 use gym; show tables; -- 看到 member, coach, course 等表说明建表成功有个非常细节的坑init.sql如果包含创建数据库语句然后切换数据库可能导致后续导入表结构时进入到默认数据库里。建议建库和建表分成两个脚本或者用source命令逐步执行这样遇到问题容易定位是哪一步失败。5.3 后端启动步骤后端修改application.yml里的数据库配置spring: datasource: url: jdbc:mysql://localhost:3306/gym?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver注意serverTimezoneAsia/Shanghai这一项。MySQL 8.0默认时区设置和国内时区差8个小时不加这个参数所有时间字段都会显示成UTC时间排查起来一脸懵。启动前的依赖安装mvn clean install -DskipTests然后启动主类GymApplication。看到日志里有Tomcat started on port(s): 8080说明启动成功。这时先用浏览器或者Postman测试接口curl http://localhost:8080/api/login -X POST -H Content-Type: application/json -d {username:admin,password:admin123}返回一个token就说明后端已经通了。5.4 前端启动与联调前端启动步骤cd frontend npm install npm run dev默认端口是8080或者配置的5173/3000。启动后访问前端页面有一个重要配置需要检查src/utils/request.js里的baseURL必须指向后端地址。开发环境推荐在Vue的vue.config.js里配置代理把/api开头的请求代理到http://localhost:8080module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样本地开发可以避免跨域问题。如果你的baseURL直接写成了http://localhost:8080那请求会跨域需要后端也配置跨域过滤器。生产环境打包则建议把Vue打包后的dist目录放到SpringBoot的static目录下做到单机单端口部署省去Nginx配置的复杂度。6. 常见问题与排查技巧实录6.1 启动报404但明明有请求路径这个问题我见过大量新手踩坑。后端端口正常启动了请求却一直404。查下来大概率是两种原因控制器类上的RestController注解没加Spring根本不认为你那个类是个接口类。前端请求路径少拼了/api前缀。排查方法很简单直接看后端日志。SpringBoot启动时会打印所有URL映射你搜一下就看到了Mapped {[/api/member/list],methods[GET]} onto ...如果没看到你期望的那条映射基本就是Controller注解或者类扫描范围的问题。重点确认GymApplication在顶层包下Controller在它的子包里否则组件扫描不到。6.2 MyBatis报Invalid bound statement (not found)这个错误说明Mapper接口和XML文件没有正确绑定。我自己的排查顺序是确认application.yml里配置了mapper-locations: classpath:mapper/*.xml。确认XML文件在src/main/resources/mapper目录下而且文件名和Mapper接口名一致比如MemberMapper.java对应MemberMapper.xml。确认XML文件的namespace属性写的是Mapper接口的全限定名。确认Mapper接口标了Mapper注解或者在启动类上加MapperScan(com.example.gym.mapper)。还有一个容易忽略的点target目录下的mapper.xml没被编译进去。本地开发时可以跑到target目录看下有没有这个XML文件没有就Maven重新clean一下。6.3 数据库连接报SSL或时区错误常见报错长这样Unable to load authentication plugin caching_sha2_password或者The server time zone value is unrecognized...第一种情况是MySQL 8.0的默认认证插件和旧驱动不兼容。解决方案要么升级MySQL驱动到com.mysql.cj.jdbc.Driver新版驱动类路径带cj要么在创建用户时用mysql_native_password插件ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY yourpassword;第二种情况就是前面说的时区问题把连接字符串加上serverTimezoneAsia/Shanghai即可。这两个都是配置类问题配置对了基本不会再出现。6.4 前后端联调出现跨域报错浏览器控制台出现Access-Control-Allow-Origin相关的报错几乎都是跨域问题。你可以有两条路前端代理法推荐开发环境使用配置vue.config.js的proxy这时代理请求是同源的浏览器不会拦截。后端CORS法推荐生产环境使用写一个配置类注入CorsFilterBean public CorsFilter corsFilter() { UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); }注意setAllowCredentials(true)和addAllowedOrigin(*)不能同时使用这是安全策略限制必须用addAllowedOriginPattern实现通配。还有一个隐藏坑需要提醒拦截器拦截了请求时设置的响应头可能被覆盖。如果你在拦截器里执行了response.setStatus(401)但没设置跨域响应头浏览器也会显示跨域报错。所以应该在拦截器的afterCompletion阶段补充跨域头或者把CORS过滤器优先级调到拦截器之前。6.5 预约功能偶发出现超卖之前讲过用条件UPDATE解决超卖但如果你之前没有这样实现而是用select ... for update注意锁的生效前提条件字段必须是索引字段。如果是全表扫描后锁行InnoDB会升级为锁表性能差很多。此外要非常明确一点for update锁的是搜索范围内的索引记录而不是“接下来要插入的行”所以后来的插入可能还涉及间隙锁复杂度远高于条件UPDATE。实践证明对于预约扣减名额这个场景UPDATE ... WHERE booked_count max_people是简单且可靠的方案。如果影响行数为0直接抛出业务异常。这个实现既简洁又不容易出错。7. 最后的经验总结我做过不少管理类系统的技术评估一个深刻的体会是这类项目的难点从来不是单点技术而是把业务流程翻译成表结构和代码的准确性。健身房管理系统的会员-课程-预约-入场这条链路放在任何一家门店管理系统里都成立。你把这套系统完整做一遍等于把SpringBoot的自动配置机制、MyBatis动态SQL的边界条件、Vue前后端数据流的协作、MySQL索引在业务查询中的真实作用全部过了一遍这些经验在面试时是能直接讲的。如果你拿到源码不管是用它跑通一个结课设计还是通过它理解一个商业系统的完整构造我都强烈建议你在跑通的基础上动手改两个地方一是增加一个“会员到期自动提醒”的定时任务二是在预约记录里增加一个“取消预约并释放名额”的接口。这两个改动虽然只是局部功能但它们会逼着你理解SpringBoot的定时任务和事务回滚在真实场景下的使用锻炼密度比单纯看代码高得多。最后再分享一个小技巧在联动调试前后端接口时不要一次性把所有接口都写完再联调按“登录-会员管理-预约-入场记录”的顺序一个模块一个模块打通。每个模块联调通了再做下一个模块出现问题能迅速收敛到最近的改动范围这个习惯能让你的开发效率至少提升30%。