如云长翩在毕业设计选型这件事上，我见过太多人栽在“技术栈过于炫技”和“项目过于简陋”这两个极端上。如果你正打算做一套Java Web方向的毕设，说实话，“SpringBoot + Vue 金帝豪斯健身房管理系统”这个题目是一个性价比非常高的选择。它的业务规模不大不小，刚好能把前后端分离、权限控制、数据库设计、接口文档这些核心技能点全部覆盖，又不会像电商系统那样把业务复杂度推到失控的边缘。这套系统我从项目结构、数据库脚本、后端接口到前端页面完整过了一遍，下面把我梳理出来的技术细节、实现思路和踩坑记录整理出来，希望能帮你减少几个通宵。
1. 项目整体设计与技术选型思路拆解
1.1 为什么选SpringBoot + Vue这套组合
先聊技术选型的逻辑。现在Java Web方向的毕设，主流方案基本就是Spring Boot + 模板引擎（Thymeleaf/JSP）和Spring Boot + 前后端分离（Vue/React）这两条路线。金帝豪斯健身房管理系统我推荐直接用前后端分离，原因有三个。
第一是展示效果更贴近真实企业开发。你可以直接说“这套项目采用前后端分离架构，后端提供标准RESTful API，前端通过Axios异步请求数据”，这句话在答辩时就是加分项。面试官或者答辩老师现在对“前后端分离”这四个字是有预期的，你做出来了，说明你对现代Web开发的主流协作模式有认知。
第二是开发效率的分配更合理。健身房的业务模块，比如会员管理、私教预约、课程排期、器械报修，它的核心逻辑在后端，前端页面主要就是表格、表单、弹窗、图表的组装。Vue + Element UI这种组件化方案，写起来比用JSP拼标签快得多，而且页面效果更现代，不会出现那种“一眼假”的后台管理系统风格。
第三是调试和部署的隔离性好。前端开发服务器和后端Spring Boot服务分别跑在不同端口，通过代理转发解决跨域。开发阶段前端用npm run dev，后端用IDEA启动，互不干扰。这种“各跑各的”模式，遇到问题也好排查——接口报错就看后端控制台，页面渲染异常就调DevTools，定位问题的时间能节省至少一半。
1.2 系统核心功能模块与业务价值分析
金帝豪斯健身房管理系统这个名字听起来像是一个具体门店的项目，但它本质上是一个典型的行业管理后台系统。它的用户角色分为管理员、教练、会员三种，围绕“人—课—场—费”这条业务主线展开。
具体来看，会员管理管的是会员档案、会员卡类型（月卡、季卡、年卡）和会员卡状态；课程管理分私教课和团操课，私教课需要绑定教练和上课时间，团操课则有固定的排期表；教练管理模块负责教练档案、擅长领域、可预约时段等信息的维护；除此之外还有器械管理（设备报修与维护记录）、订单管理（会员卡购买、课程预约产生的订单流水）、公告管理（站内通知发布）。
从业务价值的角度看，这套系统的设计逻辑和真实健身房门店的运营流程是吻合的。一个会员进店，前台需要快速完成建档、办卡、约课；教练需要查看自己的课时安排；店长需要看各类经营数据。系统把这些流程线上化之后，最大的价值是解决了信息孤岛问题——不需要再靠Excel表格和微信群去同步数据。你答辩的时候如果能把这个“业务痛点—解决方案”的逻辑讲清楚，项目深度会高一个档次。
1.3 项目结构规划：前后端分离下的工程组织方式
我拿到的这套源码是标准的Maven多模块加前端独立工程的组织方式。后端部分包名为com.jdhs，按功能模块横向拆分：controller、service、mapper、entity、config、common。其中common目录里放的是全局返回结果封装类（Result）、异常处理器、JWT工具类等等，config目录放的是跨域配置、MyBatis-Plus分页插件配置、Swagger配置。
前端部分是Vue2 + Element UI + Axios + Vue Router + Vuex的标准组合。src目录下按views、components、router、store、api这五块组织。api目录下每一个业务模块对应一个js文件，里面统一封装了axios请求，这样页面组件里不需要直接写请求URL，可维护性比随手在组件里写ajax高很多。
工程结构这块我建议你要做到“说得清楚每一层是干什么的”。答辩老师经常问“你项目的Controller层和Service层怎么分工的”，如果你能答出Controller只做参数接收和结果封装、Service层处理业务逻辑、Mapper层负责数据持久化，然后配合代码指出来，这个问题的分数就拿到了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库表设计与SQL脚本深度解读
2.1 核心数据表结构与字段设计逻辑
数据库设计是毕设项目的灵魂，也是答辩时最容易深挖的地方。金帝豪斯健身房管理系统的SQL脚本我仔细看了一遍，一共是10张核心表，覆盖了业务运转所需的全部数据：admin_user（管理员）、member（会员）、member_card（会员卡）、card_type（卡类型）、coach（教练）、course（课程表）、course_order（课程预约订单）、equipment（器械）、equipment_repair（器械报修）、notice（公告）。
拿member表举例，核心字段如下：id、username、password、real_name、phone、gender、age、height、weight、body_fat_rate、card_id、create_time、status。注意到这里用了逻辑外键card_id关联member_card表，而不是直接用card_type_id。这样设计的好处是可以直接通过member表查到某个会员当前持有的卡实例，卡是哪个类型、什么时候办的、什么时候到期，都能从会员卡表中看到。
会员卡表member_card和卡类型表card_type是分开的，这是一个很专业的设计。card_type表里存的是“月卡”“季卡”“年卡”这类定义，标价多少、有效期多少天；member_card表里存的是“某会员办了一张年卡，开卡日期是哪天，到期日期是哪天”这个具体的实例。这两个表是典型的一对多关系，把“类型定义”和“使用实例”分离，数据冗余少，扩展性也强。将来如果要加“次卡”“周卡”，只需要往card_type里插记录，不需要改表结构。
2.2 SQL脚本解读：建库建表与初始化数据
这份项目里的SQL脚本文件是直接执行就能跑的，我在MySQL 5.7和8.0上都验证过，没有兼容性问题。脚本的整体逻辑是先DROP DATABASE IF EXISTS，再CREATE DATABASE，然后USE，最后建表和INSERT初始化数据。你要注意，这个脚本是有门槛的——不是随便执行，建议你先在自己的本机MySQL里建一个新库，再执行脚本，避免误删数据。
初始化数据方面，脚本里预置了管理员账号admin、几个测试会员、几种会员卡类型、几个教练和课程记录。注意脚本里默认密码都是经过MD5加密的，不是明文。比如admin用户的密码字段值是e10adc3949ba59abbe56e057f20f883e，这是MD5("123456")。如果你在数据库里直接改密码字段，记得也要用MD5加密再写入，否则登录会失败。
关于SQL脚本，我开始时吃过一个亏——直接用source命令导入的时候报错，后来发现是字符集问题。如果你用Navicat或者命令行导入，建议在连接参数里加上characterEncoding=utf8，否则中文乱码会让人抓狂。脚本里表结构创建语句都带上了ENGINE=InnoDB DEFAULT CHARSET=utf8mb4，只要你的客户端编码正确，导入之后中文显示完全正常。
2.3 为什么会员卡设计要拆成三张表
我见过很多毕设项目把会员卡字段直接塞到member表里，结果就是member表十几列，里面既有card_type又有card_end_date。金帝豪斯这套拆法是一个值得在答辩时重点讲的亮点：设计了三张表，card_type（卡类型）、member_card（卡实例）、member（会员）。你可以在答辩时主动介绍其优势：
第一，卡类型与卡实例分离，意味着修改“年卡价格”不会影响已经卖出的卡记录的历史数据。如果价格字段只在member_card里，改价格就会把历史数据也改了，逻辑上说不通。
第二，会员卡记录独立成表，可以记录会员每一次购卡、续卡、换卡的历史，一个member对应多条member_card记录，用status字段区分当前有效卡和历史卡，天然就支持续费、换卡这些业务场景。
第三，查询性能好。通过member.card_id直接关联到当前生效的卡实例，不需要每次去会员卡历史表里筛选。这在数据量小的时候看不出区别，但逻辑上清楚很多。
给会员办续卡的时候，业务逻辑是：把旧卡实例的status置为0，再创建一条新记录，status置为1。这个逻辑放在Service层实现，用事务控制。事务这块在答辩中也很能体现基本功，记得讲清楚为什么要加@Transactional——因为“更新旧卡 + 创建新卡”是两个写操作，中间任何一个失败都会导致数据不一致。
3. 后端SpringBoot核心实现解析
3.1 SpringBoot项目配置与启动流程说明
后端部分是基于SpringBoot 2.3.4.RELEASE版本构建的，对应JDK 1.8。之所以选这个版本组合，是因为2.x是当前最主流、文档最多、网上资料最丰富的版本，遇到问题基本都能搜索到解决方案。有些新手一上来就直接用Spring Boot 3.x，结果因为JDK版本、javax包名变更（改成了jakarta）等各种不兼容问题折腾好几天，毕设时间本来就紧，没必要给自己上难度。这里顺便把配置文件application.yml的几个关键配置贴出来：
yaml复制server:
port: 8080
spring:
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/jdhs_fitness?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
username: root
password: 123456
servlet:
multipart:
max-file-size: 50MB
max-request-size: 50MB
mybatis-plus:
configuration:
log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
map-underscore-to-camel-case: true
global-config:
db-config:
logic-delete-field: deleted
logic-delete-value: 1
logic-not-delete-value: 0
这里有一个需要特别注意的地方：数据库连接串里的serverTimezone=Asia/Shanghai必须配置，否则会报时区错误。MySQL 8.x默认时区是UTC，而我们的业务数据是北京时间，如果不指定时区，查询出来的日期时间字段会差8个小时。这个问题在本地跑的时候很容易遇到，我在第一次启动项目时就因为时区问题导致新增会员记录的create_time比实际时间早了8小时，排查了半天才发现是连接串的问题。
密码存储这块用的是MD5加盐思路，其实严格说是MD5 + 固定盐。工具类里写了一个MD5Util，对密码循环加密多次再验证。现在这个方案在安全级别上不算最高，但作为毕设演示已经足够了。答辩时如果老师问到密码安全，你可以接一句“实际生产环境建议使用BCrypt，我这里是基于MD5加盐实现”，既诚实又展示了知识面。
3.2 统一返回结果与全局异常处理的设计
在前后端分离的项目里，后端接口的返回格式必须统一。金帝豪斯这套系统定义了一个Result类，所有接口都返回这个结构体，它的核心字段是code、message、data。请求成功时code为200，业务失败时code为401（未登录）、403（无权限）、500（服务器内部错误），data里放具体数据。这个设计虽然简单，但解决了前后端协作中最大的痛点——前端只需要判断code，不用每次去解析不同格式的响应结构。
与之配套的是一个全局异常处理器。在SpringBoot中用@RestControllerAdvice注解定义了一个类，在里面写了几个@ExceptionHandler方法，分别处理业务异常、参数校验异常和未知异常。这样的话，Service层抛出业务异常时，不用到处写try-catch，异常处理器会自动捕获并转成统一格式的Result返回。我印象最深的是在会员注册模块中，检查手机号是否重复时，只需要在Service里写一行代码：throw new BusinessException("该手机号已被注册")，前端就能收到一个code为500、message为该提示的JSON。这种代码写起来特别清爽。
3.3 JWT登录鉴权与权限控制的实现细节
登录鉴权是毕设答辩必问的技术点，这套系统采用JWT（JSON Web Token）来实现，我觉得有必要把原理和实现讲清楚。
JWT的核心思路是：用户登录成功后，后端生成一个包含用户身份信息的加密Token，返回给前端。前端在后续每次请求的请求头中携带这个Token（通常放在Authorization字段），后端通过拦截器验证Token的合法性和有效期，从而判断用户是否已登录。它的好处是无状态、不需要在服务端保存Session，天然适合前后端分离架构。
在代码实现上是这样的：定义一个JwtUtil工具类，里面有generateToken和parseToken两个方法。generateToken接收用户ID、用户名和角色，用HMAC-SHA256签名算法生成Token，有效期设置为24小时。然后定义一个拦截器（HandlerInterceptor），重写preHandle方法，从HttpServletRequest请求头中取出Token，调用JwtUtil.parseToken验证，通过了就放行，不通过直接返回401状态码。最后在WebConfig里注册拦截器，并配置放行路径——login接口和Swagger文档相关路径不需要Token，其余接口全部拦截。
这里我在实际调试时踩过一个坑：跨域配置和拦截器的执行顺序。如果跨域配置没有正确处理OPTIONS预检请求，前端发起的跨域请求会被拦截器拦截，导致浏览器报CORS错误。解决办法是：在拦截器里判断如果请求方法是OPTIONS，直接放行。这是前后端分离项目中的经典坑，建议你一定要处理好，否则前端半天调不通接口，最后发现是后端拦截器的锅。
3.4 基于MyBatis-Plus的数据持久化与分页查询
数据持久化层用的是MyBatis-Plus，这是MyBatis的增强工具，它在保留MyBatis原生功能的基础上，内置了很多通用方法，比如selectById、selectPage、insert、updateById等等，不需要写XML映射文件就能实现基础的CRUD操作。对于毕设项目来说，用MP能显著减少代码量，同时它提供的分页插件也很好用。
在业务查询这块，健身管理系统里最典型的一个分页查询是会员列表。它的查询条件可能有：会员姓名模糊查询、手机号模糊查询、卡类型筛选、状态筛选。在Service层的实现思路是：构建一个LambdaQueryWrapper，用like方法添加姓名字段的模糊查询条件，用eq方法添加卡类型和状态等精确查询条件，然后调用page方法传入当前页和每页条数，MyBatis-Plus会自动生成带LIMIT的SQL语句并返回分页数据。
有一点需要提醒：分页插件需要显式配置，在SpringBoot启动类或者配置类里添加@Bean注解的分页拦截器（PaginationInnerInterceptor）。如果没有配置，调用page方法不会报错，但返回的数据是全量的，分页effectively失效。这个坑比较隐蔽，我建议你拿到源码后先查一下是否已经配置了。
4. 前端Vue实现与核心功能页面拆解
4.1 Vue项目的创建、目录结构与基础配置
前端部分是基于Vue 2.6.11 + Vue CLI 4.5.0构建的，UI组件库用的是Element UI 2.15。为什么不用Vue 3？坦率地说，如果你做的是毕设而不是上线产品，Vue 2 + Element UI依然是很稳的选择——组件生态成熟、中文文档齐全、遇到问题随便搜都有答案。Vue 3 + Element Plus虽然新，但你调试慢的问题可能比新技术带来的收益更麻烦。
前端项目的目录结构是标准的Vue CLI工程：public目录放静态资源，src目录里按views、components、router、store、api再细分。main.js是入口文件，在这里注册了Element UI组件库、全局样式、路由实例和状态管理实例。axios统一封装在utils/request.js里，通过创建axios实例并设置baseURL和请求拦截器来实现。
请求拦截器是一个容易被忽略但很重要的地方。在request.js里，拦截器会从localStorage读取Token，然后在请求头中加上Authorization: Bearer
4.2 登录页面与路由权限控制的前端实现
登录页面的设计整体走的是简洁风：居中卡片，用户名、密码、验证码三个输入框，登录按钮。表单验证用的是Element UI自带的rules规则，校验用户名和密码非空。提交时调用login接口，成功后把后端返回的Token存到localStorage，再把用户信息存到Vuex中，然后通过this.$router.push跳转到首页。
路由权限控制是前端一个值得在答辩时展示的亮点。它的实现思路是：在router配置中给需要登录才能访问的页面添加meta: { requiresAuth: true }标记，然后在全局前置守卫（beforeEach）中判断，如果访问的页面需要登录且本地没有Token，就强制跳转登录页。这个方案能挡住大多数人，但严格来说它的安全性依赖前端判断，真正安全的后端接口还是要有JWT鉴权保护，两者配合才算完整。
我自己的开发体验：这个项目最好先完成后端接口再联调前端页面。如果前后端并行开发，接口字段一旦变动，前端联调的时候会反复返工。我建议你至少先把后端所有接口跑通（用Postman逐个验证），再开始写前端页面。这个顺序能帮你节省至少一天时间。
4.3 会员管理、课程预约等核心页面的实现逻辑
会员管理是健身房系统的核心页面，实现上用的是Element UI的el-table + el-dialog + el-form组合。页面加载时调用后端分页查询接口获取会员列表，展示在表格里；点击“新增会员”按钮时弹出对话框，填写表单后提交。搜索功能通过一个el-input绑定关键字，配合el-button触发查询。还有编辑和删除按钮，分别调update和delete接口，删除时弹一个确认框，防止误操作。
课程预约逻辑是这套系统里稍微复杂一点的功能。会员在前端页面选择课程，课程信息里包含教练、时间、价格、剩余名额。点击预约时，前端带上课程ID和会员ID调预约接口，后端处理的核心逻辑是：第一步检查该会员是否已预约此课程（防止重复预约），第二步检查剩余名额是否大于0，第三步扣减名额并创建预约订单记录。整个操作放在一个事务里，任何一个环节失败都会回滚。
前端交互上这里有个小细节：预约成功后需要刷新当前页面数据，把已预约的状态按钮置灰，同时调整剩余名次的展示。这个小交互在答辩时很加分，说明你考虑到了用户操作后的实时反馈。
4.4 前后端联调中的跨域与代理配置
联调阶段避不开跨域问题。开发环境下的推荐方案不是在后端配置CORS，而是用前端的devServer代理。在vue.config.js中配置：
javascript复制module.exports = {
devServer: {
port: 3000,
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true
}
}
}
}
这样配置之后，前端页面上请求的URL是/api/member/list，开发服务器会把请求转发到后端的http://localhost:8080/api/member/list，浏览器里不会产生跨域报错。这是后端代码里留了一份CORS配置作为双保险。在生产部署时，则要把前端dist目录里的静态文件放进Nginx，然后通过Nginx反向代理转发/api接口到SpringBoot服务。这些都是比较完整的部署思路，答辩时可以展开说。
5. 接口文档说明与Swagger配置实战
5.1 为什么毕设项目一定要有接口文档
我评审过不少毕设作品，一个普遍情况是：代码能跑，但问接口有哪些、参数是什么、返回什么，学生说不清楚。接口文档的意义不只是交付物好看，它其实是对后端设计能力的一次检验。一个合格的后端接口设计，应该做到URL语义清晰、请求方式正确、参数有约束、返回结构统一。
金帝豪斯这套系统交付物里附带了一份完整的接口文档（Markdown格式），包含每个接口的URL、请求方法、请求参数（名称、类型、是否必填、说明）、返回结果示例。它同时集成Swagger2，启动项目后访问/swagger-ui.html就能在线查看和调试所有接口。这里我把Swagger的核心配置贴出来：
java复制@Configuration
@EnableSwagger2
public class SwaggerConfig {
@Bean
public Docket createRestApi() {
return new Docket(DocumentationType.SWAGGER_2)
.apiInfo(apiInfo())
.select()
.apis(RequestHandlerSelectors.basePackage("com.jdhs.controller"))
.paths(PathSelectors.any())
.build();
}
private ApiInfo apiInfo() {
return new ApiInfoBuilder()
.title("金帝豪斯健身房管理系统接口文档")
.description("SpringBoot + Vue 前后端分离项目")
.version("1.0")
.build();
}
}
注意，启动项目后如果你看到404页面，先确认两件事：第一，Swagger2依赖是否引入（springfox-swagger2和springfox-swagger-ui这两个都要有）；第二，SpringBoot版本和Swagger2版本是否兼容。如果版本不匹配，会出现启动报错或者页面打不开的情况。通常SpringBoot 2.3.x配swagger 2.9.2是比较稳的，这两个版本是我踩过坑后确认的组合，其他地方如果版本高了建议调到这个组合试试。
5.2 接口文档的结构说明与关键接口解读
来看几个核心接口的实际返回结构。以查询会员列表为例：
code复制GET /api/member/list?pageNum=1&pageSize=10&name=&phone=&cardTypeId=
返回结果示例：
json复制{
"code": 200,
"message": "查询成功",
"data": {
"total": 100,
"records": [
{
"id": 1,
"username": "zhangsan",
"realName": "张三",
"phone": "13800138000",
"cardTypeName": "年卡",
"cardEndDate": "2024-06-01",
"status": 1
}
],
"pageNum": 1,
"pageSize": 10
}
}
这个接口在答辩时有一个很好的讲法：你可以在Swagger页面直接请求这个接口，然后把返回JSON和数据库实际数据对照给老师看，说明接口联通了前后端。这比PPT上贴代码有说服力得多。
另一个值得重点讲的是课程预约接口。它涉及多个业务规则的判断，是体现后端逻辑深度的地方：
- 会员是否已预约该课程（重复预约校验）
- 课程剩余名额是否大于0（库存校验）
- 课程是否已过期（时间校验）
- 预约成功后剩余名额减一（状态变更）
四个步骤对应四段清晰的服务层代码，在答辩时可以逐行分析，比普通的增删改查有分量得多。
6. 项目部署运行的完整步骤与常见问题排查
6.1 本地环境准备与启动顺序详解
整套项目的运行需要准备好以下环境：JDK 1.8及以上、Maven 3.6及以上、MySQL 5.7或8.0、Node.js 12及以上、IdeaVU或者任意一个代码编辑器（前端VSCode即可，后端用IDEA更好）。这些环境变量的配置比较基础，这里不展开，只提醒一句：如果之前装了多个JDK版本，务必在IDEA里把Project Structure的Project SDK和Modules的Language Level都设为1.8，避免编译的时候报错版本问题。
启动顺序要按照依赖关系来，建议按以下三条路线操作：
后端启动流程
- 用Navicat或者命令行执行项目根目录下的
jdhs_fitness.sql，完成建库建表和初始化数据。 - 用IDEA打开后端工程，等待Maven自动下载依赖（这一步看网络情况，可能需要几分钟）。
- 修改
application.yml中的数据库账号密码为你本机的值。 - 运行
JdhsApplication的main方法，看到Started JdhsApplication的日志说明启动成功。 - 浏览器访问
http://localhost:8080/swagger-ui.html验证后端接口是否正常。
前端启动流程
- 用VSCode或WebStorm打开前端目录。
- 在终端执行
npm install，安装项目依赖。 - 执行
npm run serve，启动开发服务器。 - 浏览器访问
http://localhost:3000，看到登录页面说明前端正常。 - 用admin/123456登录，验证前后端联调是否成功。
我最初一次搭的时候，在npm install那一步卡了半小时，后来换了淘宝镜像就好多了。执行npm config set registry https://registry.npmmirror.com再重新install，会快很多。这不是什么高深技巧，但确实能省下大量时间。
6.2 常见报错与解决方案速查表
实际操作中，我整理了一份高频问题排查对照表，列在这里供你参考：
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 后端启动报Access denied for user | application.yml中数据库密码不对 | 核对MySQL账号密码，确认字符集 |
| 执行SQL脚本中文乱码 | 客户端连接字符集不是utf8 | 连接参数加characterEncoding=utf8 |
| SpringBoot启动报端口被占用 | 8080端口已被其他进程占用 | 换端口或在任务管理器结束占用进程 |
| No 'Access-Control-Allow-Origin' header | 跨域配置未加载 | 检查WebConfig是否加了@Configuration注解 |
| Swagger页面404 | 依赖缺失或版本不兼容 | 确认springfox依赖存在，2.3.x配2.9.2 |
| 前端请求接口404 | 后端接口路径和前端api文件不一致 | 检查axios路径，确认/api前缀 |
| 前端npm run serve报Error | node_modules依赖不完整 | 删掉node_modules重新npm install |
| 登录后接口返回401 | Token过期或者请求头未带Token | 重新登录，检查请求拦截器配置 |
6.3 数据库常见操作经验与SQL脚本再说明
SQL脚本使用这块再单独说几句。脚本里除了建表和初始化数据，还预置了一些经典的查询语句作为注释，比如统计某月新增会员数、统计今日课程预约数、统计卡类型分布等。这些统计SQL在毕设中经常需要对应到图表页面——比如前端ECharts展示经营数据，后端接口返回的数据就是从这些统计SQL里来的。
实际开发中尽量不要在项目代码里直接拼接SQL字符串，像MyBatis-Plus的QueryWrapper已经能覆盖绝大多数查询场景。当你需要更复杂的多表连查时，再写对应的@Select注解自定义SQL方法，而不是往XML里堆。这个习惯能少踩很多SQL注入的坑，答辩的时候也能理直气壮地说自己考虑了安全问题。
7. 从毕设到面试：如何把项目讲出亮点
7.1 答辩准备中的项目讲解思路与话术建议
项目做完了，最后一步是把成果讲出去。答辩时时间有限，建议按“项目背景—技术选型—核心功能—亮点难点—总结展望”这个顺序讲，整体控制在8到10分钟。
项目背景不用过多展开，两分钟讲清楚健身房管理目前的痛点和你这套系统解决的业务问题就行。技术选型讲两层：一是为什么用SpringBoot（生态成熟、快速搭建、约定优于配置），二是为什么用Vue（组件化、前后端分离、开发效率高）。这里注意别只报技术名词，要带上“老师，我选择XX是因为考虑了XX问题”这种句式，显得有思考。
核心功能部分挑两个最有含金量的模块展开讲，我建议选会员管理和课程预约。会员管理可以从数据库设计切入，强调card_type和member_card分离的合理性；课程预约则重点讲事务控制和业务规则校验。这两块讲好了，技术深度基本就立住了。
亮点难点这个环节最容易出彩，也最容易翻车。我建议你准备三个自己真正遇到的问题以及解决方法，比如“我遇到前端跨域问题，最终通过后端CORS配置解决”之类的真实经历，比背一堆名词自然得多。
7.2 项目面试中常见问题与回答思路
面试环节里，面试官爱问的技术点其实就那几个，给你梳理一下：
第一个问题是“你的项目是怎么做权限控制的”。这个问题可以分两层回答：后端用JWT生成Token，拦截器校验登录状态；前端用路由守卫控制页面访问权限。如果你还能补充一句“将来可以引入Spring Security实现更细粒度的权限控制”，会显得你对技术边界有认知。
第二个问题是“MyBatis-Plus和MyBatis有什么区别”。核心答两点：MP内置通用CRUD方法，无需手写SQL；MP提供分页插件、逻辑删除、自动填充等功能。最关键的是强调“项目里用MP提高了开发效率，复杂查询仍然可以手写SQL”，这句话最稳。
第三个问题是“你怎么理解前后端分离”。这个问题的标准答案是：前端负责页面渲染和用户交互，通过HTTP协议调用后端接口获取数据；后端负责业务逻辑处理和数据处理，返回JSON格式数据；两者通过接口文档约定契约，可以独立开发、独立部署。
第四个问题是“你项目里有哪些地方用到了面向对象的设计”。可以举一个例子：把返回结果封装成Result统一对象，把业务异常封装成BusinessException，把JWT工具封装成JwtUtil。这三个例子都能体现封装思想。
7.3 基于源码的二次开发思路与扩展方向
最后聊一下如果你不想只是交一个“纯毕设”，还能往哪些方向扩展。这套系统的扩展空间其实很大，比如数据分析模块：根据会员表的body_fat_rate和身高体重的字段，可以用ECharts实现一个体脂变化趋势图，再配一个SQL统计模块，做一个经营月报。前端加上图表页面，后端加上统计接口，项目视觉丰富度立刻上一个档次。
支付功能也可以接进来。现在的场景是线下办卡付款后管理员后台操作，如果你对接一个模拟支付（比如支付宝沙箱环境），把支付状态和会员卡开通绑定，项目的业务闭环会更完整。面试讲这个的时候会非常加码。
另一个方向是引入消息通知机制。比如当会员成功预约课程后，通过邮件或者短信通知提醒（可以用Spring Boot的邮件模块或者阿里云短信SDK）。这个功能听着不复杂，但涉及异步处理和第三方SDK集成，技术含量一下就提升了。
另外如果你想用这套项目作为求职项目，建议把代码质量再打磨一下：数据库连接池换成Druid，日志系统接入Logback，单元测试补充几个核心Service层的测试用例。这些都不是必须的，但每加一个都会让简历上的项目描述更有份量。
我自己的体会是，毕设项目不追求功能大而全，但要在核心链路上做到深而细。金帝豪斯这套系统真正有价值的地方在于它把“业务—数据—接口—页面”这条链路完整地打通了。你做完之后如果能不看代码把每个模块的表结构、接口设计、核心逻辑讲清楚，那这个项目的价值就已经完全被吸收了。最后再提一句，拿到源码后别直接交，先自己从头到尾跑一遍、把每个模块的代码读一遍，再动手改一两个自己感兴趣的功能，这个过程比源码本身值钱得多。