SSM+VUE养老服务平台毕业设计全攻略：从选题、开发到答辩部署

做毕业设计这件事，最怕的不是题目难，而是题目看着简单、做着全是意外。比如"基于SSM+VUE的老人养老服务平台"这种题，光看名字会觉得：不就是SSM增删改查加一个VUE页面吗？真上手你会发现，老人信息管理、健康档案、护工排班、费用结算、家属端查看这几个模块串在一起之后，光数据库表就要设计十几张，前后端联调阶段更是每天都有新问题。这篇内容是我带学生做完一个完整养老平台之后的梳理，面向正在做SSM+VUE毕业设计、或者想快速搭一个前后端分离管理系统的同学，从选题逻辑、功能设计、后端实现、前端对接、论文书写到部署上线，一套流程全部讲清楚。核心关键词不外乎SSM、VUE、毕业设计源码和LW文档，但真正值钱的是怎么把这几个词变成能通过答辩、能写得下去的系统。

1. 为什么毕业设计选SSM+VUE的养老服务平台：选题与选型逻辑

很多同学拿到题目后会纠结两件事：第一，这个平台到底在管什么业务？第二，为什么题目指定SSM而不是现在更火的Spring Boot？这两件事想不清楚，后面做起来就是边写边改。

1.1 平台在解决什么问题：养老机构的日常管理痛点

我刚拿到这类题目时，一开始也以为"养老服务平台"就是个信息登记网站，把老人姓名、年龄、身份证号录进去就完事了。真去调研或者观察一家养老机构的日常运营，会发现管理远比登记复杂：老人入住时要登记健康档案和过敏史，家属定期要了解老人身体状况，护工每天要做护理记录，每个月要结算床位费和护理费，用药时间到了还要提醒。所以平台不能只做简单的信息录入，它必须把入住、护理、健康、缴费这条业务链串起来。

我通常会建议把系统拆成六大块：老人管理、健康档案、护理管理、床位管理、费用管理、系统管理。有的版本还会加家属登录，那就要多做一个家属端，权限模型也跟着复杂一点。模块之间的数据关系一旦理顺，后面的数据库设计和代码结构都会清晰很多，不会出现写到一半发现某个字段没地方放的情况。

1.2 为什么题目指定SSM，而不是Spring Boot？

不少学生对"SSM+VUE"有一个常见质疑：现在企业里都用Spring Boot，谁还用SSM？这个质疑本身没错，但毕业设计的选型逻辑和企业生产逻辑不完全一样。SSM作为经典的三层框架，在本科课程里覆盖率非常高，老师讲SpringMVC和MyBatis时大多数用的就是SSM，你照着课程重写一遍成本很低。第二个好处是写论文。论文里写"SpringMVC控制器层、Service业务层、MyBatis持久层"的分层结构，比写Spring Boot自动装配更容易把原理讲细，章节容量也更充足，评审老师看论文时对这类结构也最熟悉。

还有一个现实因素：毕业设计题目往往来自历年题库，老师对这类题目和代码结构已经很熟，开题、中期、答辩检查点基本不会为难你。反过来说，如果基础一般却硬要临时学Spring Boot生态，光starter配置、自动装配、部署方式就要踩一堆新坑。所以，如果题目已经指定SSM，我不建议花精力纠结"为什么不换Spring Boot"，把SSM本身做扎实就足够毕业甚至拿优了。

1.3 VUE在项目里的角色：前后端分离的正确打开方式

以前的毕业设计大多是JSP直接渲染，页面和服务端代码混在一起，每加一个页面就要写一个Controller跳转。SSM+VUE走的是前后端分离：后端只提供JSON接口，前端用Vue发Ajax请求再渲染页面。这样做的好处是目录结构清爽，演示的时候可以开两个终端分别起前后端，答辩现场更有"工程感"。

版本选择上，如果学校的教程多数还是Vue 2 + Element UI，我建议直接用Vue 2，社区资料多、遇到的坑少；如果你已经会用Vue 3，那用Vue 3 + Element Plus也没问题。对这个题目而言，技术栈的稳定性比版本新更重要，因为核心工作量在业务逻辑而不是炫酷的前端特效。

2. 平台功能地图：从数据库表反推核心模块设计

动手写代码之前，我建议先把数据库表设计出来。表结构基本决定了系统的功能边界，也决定了后续代码怎么写。下面是我实际整理的核心表结构和它们之间的关联逻辑。

2.1 三角色权限体系：管理员、护工与家属

养老服务平台通常需要考虑三类角色，有的系统还会再拆出一个"老人账号"，但考虑到老人实际使用手机的场景很少，更多是家属代为查看，所以我更推荐把账号体系收敛成三角色：

• 管理员：负责系统配置、床位分配、人员管理、费用审核，拥有最高权限。
• 护工/护理员：负责填写老人日常护理记录、健康数据录入、查看排班。
• 家属：查看老人的健康状况、护理记录、费用明细，一般只有只读权限。

权限控制用简单的访问控制表就能实现：设计一张sys_user表存账号密码和角色，后端通过拦截器判断Session或token里的角色，前端用路由守卫控制菜单显示。如果论文需要深度，可以把它写成"基于RBAC模型的权限设计"，在sys_user、sys_role、sys_menu三张标准表上扩展。

2.2 核心数据表设计：一张表捋清项目的业务骨架

下面这张表是我实际项目里的主表结构，字段做了精简，只保留关键部分，方便你对照设计自己的表：

这里有几组关联关系要注意：elder通过bed_id关联家床，通过guardian_id关联家属；care_record通过elder_id关联老人；expense通过elder_id关联收费对象。画ER图时把这几个关系标出来，论文里的总体设计部分已经完成一大半。

我还建议这个项目不要过度设计。不要在第一天就想着多租户、分库分表、读写分离，也不要在表里堆太多冗余字段。比如费用这块，用expense表记录每笔流水，需要汇总时用SQL的sum计算总额，而不是单独维护一张总额表，因为冗余字段一旦逻辑不一致，排查起来非常痛苦。

2.3 业务闭环：从入住登记到家属查看的完整流程

平台核心流程可以按时间线走一遍：

1. 老人入住：管理员创建老人档案，分配床位，绑定护工，关联家属账号。
2. 日常运营：护工登录，按排班老人列表填写护理记录和健康数据。
3. 数据回写：护理数据写入健康档案，系统可生成血压、体重等趋势数据，家属端查看。
4. 费用结算：每月或按次，根据床位费、护理等级、额外服务生成费用流水，家属在线确认，管理员标记收款。
5. 退住办理：管理员归档老人记录，释放床位。

这条流程覆盖了所有表单的增删改查逻辑。答辩时把这个讲顺，评审老师就知道你不是只写了一个空壳页面，而是真的把业务流程串起来了。

3. SSM后端落地实记：SpringMVC三层架构与MyBatis动态SQL配合

后端部分看起来是老三样，但真正写的时候，三层架构的边界、统一返回体、事务处理、动态SQL这些细节才是决定项目质量的地方。

3.1 工程结构怎么搭：war包部署方式

用IDEA创建Maven web项目，pom.xml里引入spring、springmvc、mybatis、mysql-connector、druid连接池。传统SSM是打成war包放到Tomcat/webapps下运行，需要在web.xml里加载spring和springmvc的配置。为让结构更清晰，我习惯按这样的包结构组织：

com.example.controller # Controller层 com.example.service # Service接口 com.example.serviceImpl # Service实现 com.example.mapper # MyBatis Mapper接口 com.example.entity # 实体类 com.example.common # 统一返回体、拦截器、工具类 resources/mapper # MyBatis的XML文件 resources/spring # spring和springmvc的XML配置

配置文件不要全堆在一个applicationContext.xml里。至少拆成spring-mvc.xml和spring-mybatis.xml两个，一个是MVC相关，一个是数据源和事务相关，出问题的时候排查速度能快很多。

3.2 Controller层技巧：统一返回体、跨域与参数校验

前后端分离的第一步，是先定义一个统一返回结构。我一般写一个Result类：

public class Result<T> { private int code; // 200成功，500失败，401未登录 private String msg; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.setCode(200); r.setMsg("success"); r.setData(data); return r; } public static <T> Result<T> error(String msg) { Result<T> r = new Result<>(); r.setCode(500); r.setMsg(msg); return r; } }

Controller方法统一返回Result，前端axios就能用同一个结构统一处理成功和失败。跨域方面，开发阶段最简单的做法是配置一个CorsFilter或者用@CrossOrigin，但最稳妥的还是全局配置：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowCredentials(true) .maxAge(3600); } }

这里有个坑绝大多数人都会踩：前后端分离开发时，浏览器会先发一个不带业务参数的OPTIONS预检请求。如果你在拦截器里直接把OPTIONS拦下来做登录校验，前端会一直报跨域。所以拦截器需要对OPTIONS先放行，再做真正的token或Session检查：

if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; }

3.3 Service层业务边界：把事务放在接口方法上

Service层最容易犯的错误是每个方法只做单表操作，然后在Controller里连续调好几个Service来完成一个业务。正确做法是：一个完整的业务动作封装成一个Service方法，事务注解直接加在方法上。比如"入住登记"这个动作，涉及插入老人表、更新床位状态、插入健康档案、关联护工四件事，如果散在Controller里又不开事务，任何一步失败都会留下脏数据。

我推荐在Service接口方法上加@Transactional(rollbackFor = Exception.class)，实现类里算子逻辑再调Mapper。注意粒度：事务与业务动作对应，而不是把整个Service类都加上@Transactional，那样会让内部自调用绕过代理，事务不生效还可能拖慢性能。

这个项目里值得开事务的场景至少有三个：新增老人加分配床位加创建健康档案、退住时释放床位加更新老人状态、费用结算时插入expense流水加更新老人欠费状态。每一个都是跨表的完整业务动作。

3.4 MyBatis动态SQL：多条件查询与PageHelper分页

老人管理、护理记录这类列表页，通常有多个筛选条件：姓名、床号、状态、日期区间。MyBatis动态SQL非常适合处理这种"有条件就拼条件、没条件就跳过"的查询。一个典型例子：

<select id="selectElderPage" resultType="com.example.entity.Elder"> select * from elder <where> <if test="name != null and name != ''"> and name like concat('%', #{name}, '%') </if> <if test="bedId != null"> and bed_id = #{bedId} </if> <if test="status != null and status != ''"> and status = #{status} </if> </where> order by create_time desc </select>

分页插件PageHelper也有一个高频坑：startPage必须紧跟在该语句查询之前，中间不能插入其他数据库操作，否则分页参数会被其他查询消费，导致总数和页码全乱。这也是我前面建议Service方法逻辑尽量精简的原因之一。

4. VUE前端与SSM对接：axios、路由守卫与组件化开发

前端部分，只要把工程初始化、登录鉴权、组件化拆解这三件事搞明白，剩下的页面基本都是套同一个模式。

4.1 工程初始化与版本匹配

用Vue CLI创建项目，然后按需引入Element UI和axios：

vue create elder-admin npm install element-ui --save npm install axios vue-router --save

版本匹配这块要记牢：Vue 2 配 Element UI，Vue 3 配 Element Plus，混用会直接报错。main.js里注册Element UI之后，接下来要做的是把axios实例封装成一个request模块，设置baseURL指向后端接口地址。开发阶段统一用类似http://localhost:8080/api的地址，后端所有接口也统一加/api前缀，这样后期部署做代理转发时不用改业务代码。

4.2 登录、token存储、路由守卫与axios拦截

前后端分离的登录处理，我见过太多人把用户信息直接存在localStorage里然后到处判断，很容易出问题。最小但规范的做法是：

• 登录成功后，后端返回一个token，前端把token存在localStorage。
• axios请求拦截器在每次请求的headers里带上Authorization: token。
• 后端写一个登录拦截器验证token，并把当前用户信息放进request域，方便Service层获取当前操作人。

前端路由守卫是这个环节的核心：

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

axios响应拦截器里统一判断返回的code，401则跳转登录页，500弹出错误提示。这样每个页面都不用再重复写"登录失效"的判断，代码会干净很多。这类校验逻辑在论文里也可以单独写一节，属于系统安全设计的一部分。

4.3 核心页面组件化拆解：老人信息管理的完整套路

以"老人管理"页面为例，常规做法是拆成三个组件：列表页elder-list.vue、新增编辑弹窗elder-form-dialog.vue、详情抽屉elder-detail.vue。父组件负责管理数据列表和调用接口，子组件只负责表单和事件上抛。这样维护起来舒服，论文里也能写"前端采用组件化设计，提高代码复用性"。

几个容易被卡住的细节：

• 日期控件：Element UI的el-date-picker默认绑定值是Date对象，直接传给后端可能格式对不上。建议提交时用工具方法格式化成字符串，或者后端用@DateTimeFormat配合接收。
• 图片上传：el-upload配合后端文件上传接口，上传成功后回显的是相对URL，前端需要根据环境拼接一个基础路径。
• 表格里的字典值：性别、床位状态这类字段，后端常存0/1，前端需要数组映射，不要直接在模板里写很长一串三元表达式，后期改起来很累。

4.4 Mock与代理联调：没有后端的日子怎么办

后端还没写好时，前端可以先mock数据干活。最简单的方式是在request模块里加一个useMock开关，拦截部分接口返回静态数据，不要上太重的mock框架，否则切真接口时容易漏改。

后端一旦就绪，Vue CLI项目里的联调重点就转到vue.config.js的devServer代理：

devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端请求/api/user/login会转发到后端localhost:8080/api/user/login，既解决跨域，又和后端接口路径保持一致。这里也是很多同学卡壳的地方，前端一直报跨域，其实不是后端没配置，而是浏览器预检请求没过拦截器，两个问题要一起排查。

5. LW文档撰写与答辩演示的关键细节

代码写完只是完成了一半，LW文档（毕业论文Word文档）和答辩演示才是决定评分的关键。很多同学系统做得不错，但论文措辞空泛、答辩讲不到点上，分数就是上不去。

5.1 论文大纲与写作顺序

我建议的主体结构如下：

• 第一章 绪论：背景、意义、国内外现状、本文主要工作
• 第二章 相关技术介绍：SSM、VUE、MySQL等
• 第三章 需求分析：功能需求、用例分析、可行性分析、非功能需求
• 第四章 系统设计：总体架构、功能模块划分、数据库设计、ER图、主要表结构
• 第五章 系统实现：分模块讲实现效果，配截图和关键代码
• 第六章 系统测试：测试环境、功能测试用例表、测试结果分析
• 第七章 总结与展望

这里有一个写作技巧：不要从第一章开始写，先把第五章系统实现和第四章数据库设计写完。因为代码跑通之后功能模块长什么样你已经完全清楚，倒推回去写需求分析和用例图，会写得非常真实。如果先憋绪论，大概率只能写出空话。

5.2 图表材料的准备顺序：ER图、流程图、用例图和界面截图

论文里需要大量截图，建议系统做完后集中收集，不要边写边截。至少要准备：登录页、老人管理列表、新增弹窗、护理记录页、费用管理页、健康数据图表页这些界面截图。图表材料按下面顺序准备最顺：

1. 用例图：说明角色和功能
2. 系统架构图：说明前后端分离结构和三层架构
3. ER图：用数据库设计工具直接从表结构生成，标注主外键
4. 界面截图：作为系统实现章的主要插图
5. 时序图：选一张核心的，比如登录校验或入住登记流程，插在详细设计里很加分

画ER图和用例图时，必须做到图和代码完全一致。如果论文里画了"家属端可以查看用药提醒"但系统里根本没这个功能，答辩时老师随便点一个界面验证就会露馅，交稿前一定要做一遍图表和功能的对应检查。

5.3 答辩现场高频问法和高分演示脚本

答辩环节老师喜欢问的问题其实高度重复，提前准备就能应付：

• SSM三层架构里每个层的作用？一个请求从页面到数据库是怎么走的？
• 为什么养老平台要用MyBatis动态SQL？它解决了什么场景问题？
• 数据库里elder表和bed表是什么关系？为什么这样设计？
• 前端路由守卫做了什么？token过期怎么处理？
• 系统有哪些安全性设计？登录拦截、统一返回码、防止未授权访问？
• 你觉得自己的系统相比网上的成品，有哪些改进点？

演示建议按脚本走：先演示登录与不同权限角色的菜单差异，再演示核心的入住登记流程（新增老人、绑定床位、提交），接着演示护理记录的填写和列表分页查询，最后演示费用结算。整个过程控制在5分钟左右，不要临时乱点。测试数据提前准备好，比如固定的账号密码、带数据的老人记录，就算现场紧张也能顺利走完。

6. 从跑通到上线：打包部署与常见坑位排查

毕业设计做到最后总要能运行、能演示。如果只是本地IDEA跑，那部署知识会缺一大块；如果能在演示时展示标准的部署流程，绝对是加分项。

6.1 后端war部署与前端打包

后端在IDEA里执行mvn clean package后，会生成war文件，把它复制到Tomcat的webapps目录，启动Tomcat即可。前端执行npm run build生成dist目录。如果前后端完全分离部署，可以用Nginx托管dist并反向代理后端接口。

下面这份Nginx配置可以直接借鉴，适合本地演示环境，前端在8081、后端在8080：

server { listen 8081; server_name localhost; location / { root /usr/local/elder-admin/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

try_files $uri $uri/ /index.html;这一行是Vue Router的history模式必需的，不写的话刷新页面会直接404，这一点一定要谨记。

6.2 我实际踩过的五个坑位清单

我把这个题目里出现概率最高的坑整理成表，如果你做到某一步卡住了，可以按这个顺序排查：

6.3 如果后续想升级成Spring Boot

毕业设计交完以后，如果你还想把这个题目继续做成项目，最顺的升级路线是保留MyBatis和Service层代码，把Spring配置迁移成Spring Boot自动配置。Controller层几乎可以不动，主要改动集中在web.xml消失、spring-mvc配置迁移到注解、数据源改用application.yml配置。这样一套SSM的代码资产没有浪费，面试时还能顺带讲清楚"从SSM迁移到Spring Boot时哪些结构可以留、哪些要重构"，这本身就是一个很讨喜的加分项。

写到这里，我自己的体会是：这个题目做完之后最值钱的不是SSM和VUE本身的技术难度，而是业务流程能不能捋清楚、数据库设计是否合理、文档和代码是否一致。带学生做这类项目时，我最推荐的做法是先花一个周末把数据库表和核心流程画干净，再动手编码，跑通入住登记到护理记录到费用结算这条主干流程之后，所有页面基本都是在套同一个模式，后面的效率会越来越高。祝大家答辩顺利。