SSM+Vue健身房管理系统毕设全攻略：从搭建到答辩一篇文章搞定-平芜编程栈

如果你的毕设题目恰好是“SSM+Vue健身房管理系统”，那这篇文章你应该能从头用到尾。这个题目在毕设圈里算是经典配置：SSM撑后端业务逻辑，Vue管前端页面交互，健身房场景天然覆盖了会员、课程、教练、器材、预约订单、统计报表这些模块，功能丰富但不烧脑，做系统、写论文、准备答辩都有足够的素材可挖。

我做毕设这几年帮人改过不少同类项目，也踩过不少坑。这篇文章就把我从选题拆解、后端搭建、前端开发、联调排错到论文答辩的完整经验梳理出来。里面不会给你一堆空话，而是直接告诉你怎么建工程、怎么建表、怎么写接口、怎么写前端页面、论文每一章填什么内容，以及那些文档里永远不会写但你一定会遇到的坑。

1. 毕设题目拆解：SSM+Vue健身房管理系统到底在考察什么

1.1 技术选型背后的真实逻辑

先聊一句你可能没想过的问题：为什么很多学校到现在还让学生用SSM，而不是Spring Boot？

答案很简单：课程大纲还停留在十年前。SSM（Spring + SpringMVC + MyBatis）这套组合曾经是JavaWeb的绝对主流，很多高校的《JavaEE框架》课程内容一直没更新，老师讲课用的是SSM，出题范围自然也圈在SSM里。Spring Boot你私下要不要学？当然要。但毕设题目写着SSM，你就得先按SSM的规矩来，否则答辩时第一句“为什么不用Spring Boot”就能把节奏打乱。

SSM这套框架组合拆开来看各有分工：

Spring管对象，也就是IOC容器和依赖注入。它把Service、Mapper这些对象的创建和装配交给容器统一管理，你不用到处new对象。
SpringMVC管请求分发，前端发来的URL会先经过DispatcherServlet，再由HandlerMapping找到对应的Controller方法，参数绑定、JSON返回都在这一层完成。
MyBatis管数据库操作，Mapper接口定义方法，XML文件写SQL，把Java对象和数据库记录之间的转换处理得比较干净。

Vue则负责视图层。2026年的毕设如果还写纯JSP或者静态页面，真说不过去。Vue组件化开发配合Element UI组件库，搭建管理后台的效率能比传统模板引擎翻好几倍。

这个技术栈的组合价值在于：它照顾了学校对“基础框架”的考察要求，同时你又能证明自己掌握了当前主流的工程化开发模式。你可以放心大胆做毕业设计，但如果导师允许，将 SSM 平稳地升级为 Spring Boot 的组合方式，也并不会有任何结构上的影响。因为核心业务代码不关心框架那一层，你完全可以做到“表层是SSM，里子的很多写法贴近Boot习惯”。

1.2 系统功能模块设计：不是拍脑袋，而是围绕业务场景展开

健身房管理系统听起来范围很大，但真正落到“管理后台”这个层面，核心其实就几类角色和职能：

管理员：管会员、教练、课程、器材、订单、公告、统计报表。
教练：查自己的课程排课、查看预约该课程会员的名单、维护个人课程记录。
会员：注册登录、浏览课程、预约课程、查看个人预约历史、续费记录。

围绕这三个角色，系统里最具代表性的功能点包括会员管理（含会员卡种类和到期日期）、课程安排（含教练绑定、时间和容量限制）、私教预约/团课预约、器材设备台账、充值续费订单、数据可视化报表。

我特别建议你在设计模块时留一个“公告栏模块”。很多学生忽略这个，但它有以下好处：不要小看它的作用：

给管理员角色一个相对轻量的操作场景，也是登录后台后首页展示的填充内容。
论文的“关键功能截图”部分可以多一张图。答辩PPT也多一个页面撑场面。
实现了“简单内容管理”，评语里看起来功能完整性更好。

1.3 适合什么基础的同学选这个题

选这个题目的人群大致分两类：

第一类是跟着学校课程正常走完，Spring、SpringMVC、MyBatis都学过但没系统性做过完整项目的。这个题目难度适中，你有基础但需要补的是前后端分离后接口联调、Vue组件通信那部分内容，相当于进阶一轮。

第二类是基础薄弱、平时代码写得少的。这个题目对你来说不算轻，但比“数据可视化大屏”“推荐算法”这种硬核题友好太多。系统功能逻辑清晰，没有复杂算法，也没有并发难题，数据表关系简单，CRUD就能覆盖80%以上的功能。只要肯下功夫跑通一套完整流程，答辩完全能应对。

我的结论：这是一个选得聪明、性价比高的毕设题目。接下来我按后端到前端到论文的顺序，把每一步具体怎么做拆开讲。

2. 后端SSM框架的搭建与核心实现

2.1 Maven工程结构：很多人第一步就栽在这里

先建工程。IDEA里直接新建Maven项目，勾选Web骨架是不必要的，直接选普通Maven Java工程，然后自己补目录。因为SSM项目往往需要引入Tomcat插件方式。

推荐工程结构是这样的：

gym-admin ├── pom.xml ├── src │ ├── main │ │ ├── java │ │ │ └── com/gym │ │ │ ├── controller │ │ │ ├── service │ │ │ ├── dao │ │ │ ├── entity │ │ │ ├── config │ │ │ └── common │ │ ├── resources │ │ │ ├── mapper │ │ │ ├── jdbc.properties │ │ │ ├── spring-mybatis.xml │ │ │ ├── spring-mvc.xml │ │ │ └── log4j.properties │ │ └── webapp │ │ └── WEB-INF/web.xml

pom.xml里你需要把这几组依赖配齐：

spring-core、spring-context、spring-web、spring-webmvc、spring-jdbc
mybatis、mybatis-spring
mysql-connector-java（或mysql-connector-j）
druid连接池
jackson-databind（用于JSON序列化）
javax.servlet-api（编译期，Tomcat容器提供）

用Maven需要在pom里配阿里云镜像，不然依赖下载速度会让你怀疑人生。在~/.m2/settings.xml里加上镜像源，配完后再进行依赖的导入。

注意：版本兼容是个大坑。Spring用5.x，MyBatis用3.5.x，mybatis-spring用2.0.x，这三个大版本必须匹配。我见过有人Spring 4和mybatis-spring 2.0混用，启动时直接报错找不到SqlSessionFactory的bean。最稳的搭配是 Spring 5.2.x + mybatis 3.5.x + mybatis-spring 2.0.6 + mysql-connector-java 8.0.x。

web.xml配置要注意，SpringMVC的DispatcherServlet映射建议写成/，表示接管所有请求，让Controller去路由分发。如果你的前端项目部署时是单独的静态资源目录，那么后端接口前缀统一加/api，这样可以避免接口路径和前端静态资源的路径冲突。

2.2 数据库表设计：健身房系统的数据模型核心

再说一遍，健身房管理系统不需要复杂的表关系，但表结构设计得好不好，直接决定你写代码和写论文的顺畅程度。下面是我建议的核心表和关键字段：

user表（登录账号表）

字段包括id、username、password、real_name、role（admin/trainer/member）、status、create_time。这张表统一做登录认证，会员资料另存到member表，通过user_id关联。

member表（会员信息表）

字段有member_id、user_id外键、name、gender、phone、card_type（月卡/季卡/年卡）、start_date、end_date、remain_count、status。这个表是健身房业务的核心，字段要跟会员卡的逻辑走。比如按次卡的话，需要remain_count来记录剩余次数。

trainer表（教练表）

trainer_id、user_id、name、phone、specialty、introduction、photo。教练和课程一对多，一个教练可以上多节课。

course表（课程表）

course_id、course_name、trainer_id、category（瑜伽/力量/有氧等）、class_time、duration、max_people、current_people、location、status。这里的current_people可以在预约成功后更新，也可以在查询时按预约记录聚合计算。两者选其一，别在Controller里一会儿用这个一会儿用那个，后期查bug查到怀疑人生。

appointment表（预约记录表）

appointment_id、member_id、course_id、appointment_time、status（已预约/已取消/已完成）。一个会员同一时间段不能约两节课，这个校验逻辑在Service层做，插入前先查一次是否已有同时间段的预约。

equipment表（器材设备表）

equipment_id、equip_name、type、purchase_date、last_maintain_date、status。器材模块在答辩时很加分，因为能体现设备的生命周期概念，而不是一删了之。

order表（订单/续费记录表）

order_id、member_id、order_type（新办/续费/购课）、amount、pay_method、create_time、operator_id。会员卡到期提醒功能就依赖这个表。

announcement表（公告表）

announcement_id、title、content、publish_time、publisher。

建表时一定让所有表的创建时间和更新时间字段齐全，mapper层自动填充create_time。论文里的数据库设计章节截几张表结构图就够用了，不用全都贴上去。

写SQL时，字段命名风格要统一。我建议全部下划线命名，比如create_time、course_name。同时为了减少MyBatis的映射问题，在mybatis-config.xml里开启驼峰映射：

<configuration> <settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings> </configuration>

这样create_time能自动映射为实体的createTime字段，省去一堆resultMap。

2.3 Controller-Service-Mapper三层代码：以会员查询为例

后端代码的关键是写出一套模板化的CRUD。大部分模块都会雷同，但你要清楚每个模块之间不同的地方在哪。拿会员模块举例，一套完整的接口包含：

分页查询会员列表
根据id查会员详情
新增会员
编辑会员
删除会员（或者软删除）
续费/更改会员卡状态

Controller层只做参数接收和结果封装，不写业务逻辑。举个例子：

@RestController @RequestMapping("/api/member") public class MemberController { @Autowired private MemberService memberService; @GetMapping("/list") public Result list(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer pageSize, String keyword) { PageResult<Member> pageResult = memberService.pageQuery(page, pageSize, keyword); return Result.success(pageResult); } @PostMapping("/add") public Result add(@RequestBody Member member) { memberService.addMember(member); return Result.success(); } }

注意这里的Result是我自定义的统一返回类，结构是{code: 200, msg: "操作成功", data: ...}。前后端分离后，接口返回格式必须统一，不能让有些接口直接返回数组，有些返回对象，前端处理会非常难受。建议一开始就封装一个Result<T>工具类。

Service层处理业务逻辑，比如新增会员时要校验手机号是否已存在、自动计算会员卡到期日期：

@Service public class MemberServiceImpl implements MemberService { @Autowired private MemberMapper memberMapper; @Override public void addMember(Member member) { if (memberMapper.selectByPhone(member.getPhone()) != null) { throw new BusinessException("该手机号已注册"); } // 如果办了年卡，end_date是明年今天 if ("年卡".equals(member.getCardType())) { member.setEndDate(LocalDate.now().plusYears(1)); } member.setCreateTime(new Date()); memberMapper.insert(member); } }

这个BusinessException是自定义异常，配合全局异常处理器，把校验信息统一返回给前端。别在Controller层写try-catch然后返回200，那样接口就算业务失败，前端也分不清状态。

Mapper层在XML里写SQL。XML文件放在resources/mapper目录下，和Mapper接口包路径保持一致。

<select id="selectByPhone" resultType="com.gym.entity.Member"> select * from member where phone = #{phone} </select>

分页查询我建议直接用PageHelper，只需要引入依赖并配置一下插件，就能让分页参数自动生效：

<plugins> <plugin interceptor="com.github.pagehelper.PageInterceptor"> <property name="helperDialect" value="mysql"/> </plugin> </plugins>

然后在Service层调用：

PageHelper.startPage(page, pageSize); List<Member> list = memberMapper.selectPage(keyword); PageResult<Member> result = new PageResult<>(); result.setTotal(new PageInfo<>(list).getTotal()); result.setList(list);

2.4 JWT认证与权限控制：为什么毕设也要加Token

我见过不少学生的毕设登录做得很原始：写个flag放到session，前端判断一下有没有登录就完事了。这种方案在前后端分离架构下其实很别扭，Vue部署在一个端口，后端API在另一个端口，Session跨域处理起来极其难受。

更合理、也更像真实项目的方案是JWT。登录成功后，后端根据用户名和密码校验通过，用userId和role生成一个token返回给前端，前端存在localStorage，之后每次请求在请求头带上Authorization: Bearer token。后端通过一个拦截器对需要登录的接口做校验。

JWT生成部分可以简单用io.jsonwebtoken:jjwt，封装成工具类：

public class JwtUtil { private static final String SECRET = "your-secret-key"; private static final long EXPIRE = 7 * 24 * 60 * 60 * 1000L; public static String createToken(Integer userId, String role) { return Jwts.builder() .claim("userId", userId) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }

拦截器统一做认证，注意放行登录接口和课程列表这种公开接口：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if ("OPTIONS".equals(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { try { Claims claims = JwtUtil.parseToken(token.substring(7)); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { response.setStatus(401); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"登录已过期，请重新登录\"}"); return false; } } response.setStatus(401); return false; } }

权限控制那块，我在Interceptor里把role放在request属性中，再由具体的Controller方法做角色判断。这种方案比写一个复杂的RBAC权限框架要省时间，对于毕设完全够用。论文里你可以说“采用了基于JWT的身份认证方案，接口通过拦截器进行统一鉴权，角色权限通过注解式校验实现”。

3. 前端Vue项目的创建与页面开发

3.1 Vue环境安装与项目创建：从零到一

接下来是前端。在做Vue开发前，需要先安装Node.js环境。到官网下载LTS版本的Node安装包，一路next，然后打开终端验证：

node -v npm -v

如果都打印出版本号，就说明安装成功。国内网络环境，建议把npm源设置为淘宝镜像：

npm config set registry https://registry.npmmirror.com

然后创建Vue项目。用Vue CLI的命令行工具：

npm install -g @vue/cli vue create gym-web

选择Vue 3的预设（严谨说，如果你的学校教材还在讲Vue 2，也可以选Vue 2，因为Element UI和Vue2配合已经非常成熟。如果导师没硬性要求，我建议直接Vue 3 + Element Plus，毕竟2026年了，新项目没理由再开倒车）。

创建完成后进入项目目录，安装你需要的依赖：

npm install axios element-plus vue-router@4

如果你用的是Vue 2，则安装：

npm install axios element-ui vue-router@3

注意：vue-router版本和Vue大版本是强相关的，Vue 2对应router 3，Vue 3对应router 4。装错版本是前端最常见的报错原因之一。

项目创建后，目录结构大致是：

src ├── api // 接口请求封装 ├── assets // 静态资源 ├── components // 公共组件 ├── router // 路由配置 ├── store // 全局状态管理（如果用了Pinia/Vuex） ├── views // 页面组件 ├── App.vue └── main.js

开发时在终端运行npm run serve，默认会启动在8080端口。首次启动如果报错提示端口被占用，改个端口或者关掉旧进程就行。

3.2 路由设计与侧边菜单：Vue Router的实战用法

路由是管理后台的骨架。典型的路由设计如下：

const routes = [ { path: '/login', component: () => import('@/views/Login.vue') }, { path: '/', component: Layout, // 主框架，包含侧边栏和顶栏 redirect: '/dashboard', children: [ { path: 'dashboard', name: 'Dashboard', component: () => import('@/views/Dashboard.vue'), meta: { title: '首页统计', icon: 'HomeFilled' } }, { path: 'member', name: 'Member', component: () => import('@/views/member/MemberList.vue'), meta: { title: '会员管理', icon: 'User' } }, { path: 'course', name: 'Course', component: () => import('@/views/course/CourseList.vue'), meta: { title: '课程管理', icon: 'Calendar' } } ] } ]

Element Plus的el-menu组件可以直接遍历路由meta生成侧边菜单，关键是router模式：

<el-menu :router="true" :default-active="$route.path"> <el-menu-item v-for="item in menuList" :key="item.path" :index="item.path"> <el-icon><component :is="item.meta.icon" /></el-icon> <span>{{ item.meta.title }}</span> </el-menu-item> </el-menu>

登录后要把用户角色存起来，根据角色动态过滤菜单项。管理员看到全部菜单，会员只看到课程预约和自己的预约记录。这个过滤逻辑放在路由守卫中实现，在router.beforeEach里判断：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (!token && to.path !== '/login') { next('/login') } else if (token && to.path === '/login') { next('/') } else { next() } })

简单一点做法就行，答辩被问“如何保证未登录用户不能访问后台？”的时候，你能说出这段代码，老师基本就满意了。

3.3 Axios请求封装与跨域配置：把接口联调做顺

每个前端项目到后期最乱的都是请求代码。如果你的项目里每个组件都直接axios.get('http://localhost:8080/api/member/list')这么写，后期维护会非常痛苦。建议统一封装axios实例：

import axios from 'axios' import { ElMessage } from 'element-plus' const request = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：每个请求自动附带token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) // 响应拦截器：统一处理错误 request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.msg || '请求失败') return Promise.reject(new Error(res.msg)) } return res }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') window.location.href = '/login' } else { ElMessage.error('网络异常，请稍后重试') } return Promise.reject(error) } ) export default request

BaseURL写成/api，前端开发服务器配置proxy转发到后端，这在Vue CLI项目里通过vue.config.js实现：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

后端接口/api/member/list，前端请求发到/api/member/list，devServer把这个请求转发到后端真正的地址，这就解决了前后端分离开发时的跨域问题。

如果项目部署到生产环境，有两种方案：一种是把前端打包后的dist静态资源放到Nginx里，通过Nginx反向代理/api路径到后端服务；另一种是直接打包进Tomcat的webapps目录。推荐用Nginx，更符合实际工作场景，而且论文里可以加一节“系统部署”，写起来内容更丰富。

注意：Vue开发服务器默认端口是8080，后端Tomcat也是8080，一起跑会端口冲突。最好把Vue devServer端口改成8081，后端保持8080。两者不冲突后再开发，联调效率会高很多。

3.4 核心页面实现：会员管理、课程预约、数据统计

会员管理页面是典型的“表格+弹窗表单”组合。表格用el-table展示数据，顶部放搜索框和新增按钮，弹窗里放el-form做新增和编辑。翻页就用el-pagination，把页码和页大小传给后端。

我建议在实际开发中，先把会员管理这个页面完整做出来，因为它是信息管理类页面的通关模板。后面的教练管理、课程管理、器材管理基本就是在复制模板的基础上改字段和请求地址。这不是偷懒，这是工程化的合理复用。

课程预约页稍微特殊点：会员登录后看到可预约课程列表，每节课有剩余名额。点击预约时调后端预约接口，后端校验是否有冲突、是否已满员，然后返回结果。前端拿到结果后提示成功或失败，并刷新列表数据。这个页面能体现“用户操作触发状态变更”的交互逻辑，比纯CRUD页面更能体现技术含量。

数据统计页用ECharts画图，展示会员增长趋势、课程预约人数、营收分布等。ECharts和Vue组合起来很简单，安装echarts依赖，然后直接在组件里初始化图表实例。记得在组件销毁时调用chart.dispose()，否则切换路由会报内存泄漏警告。

4. 前后端联调：最容易出问题的环节

4.1 接口文档先行：能省掉一半的返工时间

前后端分离项目中，联调期的痛苦大多来自接口约定不一致。如果你做前后端分离开发，建议把接口约定先列出来。不一定要专门建Apifox项目，但至少要在一张表里整理清楚：接口路径、请求方法、请求参数、返回数据结构。

以下面这套接口表为例，照着定义就行：

模块	方法	路径	参数	返回
登录	POST	/api/login	{username, password}	{token, role}
会员列表	GET	/api/member/list	page, pageSize, keyword	{code, data:{list,total}}
新增会员	POST	/api/member/add	JSON对象	{code, msg}
课程列表	GET	/api/course/list	无	{code, data:[...]}
预约课程	POST	/api/appointment/add	{courseId}	{code, msg}
取消预约	PUT	/api/appointment/cancel	{appointmentId}	{code, msg}
统计报表	GET	/api/stats/overview	无	{code, data:{...}}

接口约定越早确定，联调时踩的坑越少。我自己在带项目时，会对这些接口达到尽可能统一：分页参数统一叫page和pageSize，返回数据统一包在data字段里，时间字段统一用字符串yyyy-MM-dd HH:mm:ss格式返回，避免前后端因时间格式不一致反复调试。

4.2 联调中的坑和排查思路

联调时最典型的几个问题，我按出现频率从高到低排一下：

问题一：前端请求到不了后端

多半是proxy配置没生效，或者请求路径写错了。你先在浏览器Network里看请求URL是什么，如果显示的是http://localhost:8081/api/...说明走了代理，再看Response是否404，404就是后端没有这个接口路径。用Postman直接调后端接口确认后端没问题，然后排查前端路径。

问题二：后端返回了但前端报错

常见原因是返回格式和前端预期不一致。比如前端封装里写了res.code !== 200，但后端返回的是{code: 0, msg: "success"}，那前端永远会认为请求失败。方案是统一前后端约定。我在前面的Result封装中直接约定code固定为200表示成功，这个值不要变来变去。

问题三：跨域报错

在前端开发阶段因为有proxy，一般不出现跨域。但如果直接请求后端地址，或者后端部署后生产环境配置不对，浏览器会报CORS policy错误。这时从后端配置全局CORS支持，或者用Nginx配置反向代理，两条路选一条。

5. 论文写作：框架有了，论文怎么填充

5.1 论文结构安排：八章内容一次理顺

论文结构参考你学校模版，大部分学校允许的通用结构如下：

摘要
第一章绪论（研究背景与意义、国内外研究现状、主要研究内容、论文组织结构）
第二章相关技术介绍（SSM框架、Vue、MySQL、ECharts）
第三章系统分析（可行性分析、需求分析、功能需求、非功能需求、用例图）
第四章系统设计（总体架构、功能模块设计、数据库设计、接口设计）
第五章系统实现（每个功能模块的界面截图+核心代码+实现说明）
第六章系统测试（测试环境、功能测试用例、测试结果分析）
第七章总结与展望

这套结构在所有Java毕设论文中通用性非常强。你换一个题目，比如“图书馆管理系统”“在线考试系统”，章节结构完全不用变，只要改内容和截图就行。

5.2 需求分析和系统设计：高分论文的关键章节

很多同学的论文写得像流水账：登录模块截图、会员管理模块截图、课程管理模块截图……全部是“我做了什么”的展示，完全看不到“为什么这么做”。

这里教一个写法技巧：每个模块写“需求描述、业务规则、实现流程、界面说明”四步。拿会员续费举例：

需求描述：会员卡到期后需要续费才能继续使用健身房服务。
业务规则：续费时选择卡类型，系统自动计算新的到期时间；续费后会员状态自动更新。
实现流程：管理员在会员管理页面点击“续费”，弹出续费表单，选择卡类型后提交，后端校验会员状态并更新到期时间和订单记录。
界面说明：配一张截图，简单描述页面的布局和交互。

需求分析部分要画用例图。管理员用例包括会员管理、教练管理、课程管理、器材管理、订单管理、公告管理、数据统计。会员用例包括注册登录、浏览课程、预约课程、查看个人记录。教练用例包括查看课程安排、查看预约名单。用例图不用画太复杂，把角色和功能的关系表达清楚就行。

数据库设计章节除了表结构，最好画一张ER图（实体关系图）。微信搜索一堆在线绘图工具可以画，这张图在论文里是很加分的。有这张图，老师知道你真的理解了表之间的关联，而不是瞎建了一堆表。

5.3 答辩准备：高频问题清单与回答思路

答辩是最容易被问倒的一环。我把常见答辩问题列出来，建议你每个都提前准备：

问题一：为什么选择SSM框架？

回答思路：SSM是JavaWeb经典框架，Spring负责对象管理和事务，SpringMVC支持RESTful风格接口开发，MyBatis灵活管理SQL语句。这套组合结构清晰，适合中小型管理系统。同时我掌握了核心概念，后续也能平滑过度到Spring Boot。

问题二：系统有哪些角色？权限是怎么控制的？

回答思路：管理员、教练、会员三种角色。登录后通过JWT Token携带角色信息，前端根据角色动态渲染菜单和按钮，后端拦截器对所有业务接口做登录校验，在需要特定角色的地方做二次校验。

问题三：某张数据表的设计思路是什么？

拿预约表举例：预约记录包含会员ID和课程ID，外键关联确保数据完整性。同一时间段重复预约的校验放在Service层处理，先在预约表里查是否存在该会员该时间段已生效的预约记录，有则抛出业务异常。

问题四：为什么要用前后端分离架构？

回答思路：前后端分离后，前端专注页面交互，后端专注业务逻辑，两边可以并行开发。接口以JSON格式交互，前端通过Nginx部署，后端独立运行，系统结构更清晰，也方便未来做多端适配。

问题五：系统怎么解决并发预约同一门课程的问题？

这是个加分题。回答思路：一方面通过MySQL的行级锁或者乐观锁控制更新，另一方面在代码层面先select当前预约人数判断是否满员，再insert预约记录。严格的方案是用数据库事务配合SELECT ... FOR UPDATE锁行，保证判断和写入的原子性。你只要能说出这个思路，答辩老师基本不会追问下去。

6. 常见问题与排错经验速查

最后把开发过程中最常见的问题整理成一张速查表，做毕设的时候遇到对应情况对照处理就行。

问题现象	可能原因	处理方法
Maven依赖一直下载不动或失败	网络访问Maven中央仓库慢	在settings.xml配置阿里云镜像
Tomcat启动报端口被占用	8080端口被其他进程占用	改server.xml端口或关闭占用进程
项目启动报ClassNotFound异常	依赖缺失或版本冲突	检查pom.xml依赖，mvn dependency:tree排查冲突
数据库连接失败	url、用户名、密码不匹配或驱动版本不对	检查jdbc.properties配置，确认mysql驱动类路径
MyBatis查询结果全为null	字段下划线未映射到驼峰	开启mapUnderscoreToCamelCase
前端页面空白且控制台报错	路由配置或组件引入路径错误	检查router/index.js和import路径大小写
npm install非常慢	默认源为国外镜像	设置淘宝镜像源
接口返回401	token过期或没传Authorization头	检查token缓存和登录过期逻辑
前端跨域报错	开发环境proxy没生效或生产环境未配置	检查vue.config.js的proxy配置，生产用Nginx反代
修改数据库表结构后程序不生效	MyBatis缓存或旧实体类字段没同步	清缓存重启，更新实体类和Mapper映射

还有一个心态层面的建议：做毕设的时间规划上，代码尽量前紧后松。如果你还有论文没动笔，强烈建议开发每完成一个模块，就顺手把截图保存到一个专门的文件夹里，写论文时直接拖图、写说明文字，不用再去重新运行系统补截图。截图要有代表性，比如新增会员前后的列表状态对比、预约满员后按钮置灰、统计页面的图表效果，这些应用截图在写“功能实现效果”时很重要。

另外，数据库备份也要养成习惯。开发过程中写错一条delete语句把数据清空的事情太常见了，每条建表语句结束后就顺手insert几条演示数据，然后用mysqldump或者Navicat备份一份，后续把系统初始化演示数据时直接恢复。很多同学答辩前才想起来要补数据，那时候手忙脚乱，提前准备好就从容很多。

我个人在实际操作中的体会是：这套SSM+Vue的前后端分离方案，折腾过一次之后，对你的能力提升是全方位的。你既走了JavaWeb经典框架的老路，又接触了现代前端工程化，面试时被问到SSM基础问题时你答得上来，被问到Vue组件通信时你也能接得住。做这个题目的过程中，把“从数据库表设计到页面一行行代码”这整条链路完整跑通，比单纯背任何八股文都有用。

如果你正在做这个毕设，希望这篇内容能帮你少走点弯路。项目开发中如果卡在某个具体报错上，先按上面是最常见坑排查，再回到框架源码里找线索，基本都能解出来。祝顺利。