每年年初，都是计算机类专业学生集中找毕业设计选题的时候。我翻看各类技术社群的聊天记录，出现频率很高的一条消息大致是“毕设项目·SSM老年人生活管理系统，可做JAVA、PHP、爬虫、APP、小程序”，后面跟着“源码+演示录像，白嫖”之类的说明。第一次看到这个标题时，我其实没太当回事：SSM框架做了这么多年，再套一个“老年人生活管理”的业务壳，感觉就是经典增删改查的集合体。不过，当我把这个系统从头到尾独立做了一遍之后，我发现这个看似普通的选题，如果认真拆解，其实非常值得写一篇完整的复盘笔记。
这篇文章写给谁呢？主要是准备拿类似题目做毕业设计，或者刚接触SSM全家桶、想找一个完整业务案例练手的同学。我会按需求拆解、技术选型、数据库建模、核心代码实现、联调排错、答辩准备这条线，把一套能完整运行的老年人生活管理系统讲透。你不需要提前懂很多，只要会Java基础和简单的SQL，跟着一步步来，就能把这个项目从“会抄”变成“懂做”。
1. 选题核验：老年人生活管理系统到底要做什么
1.1 业务不复杂，但要能讲清楚服务流程
很多同学拿到这个题目，第一反应是“这不就是一个用户管理加上信息展示的系统吗”。如果只做到这一步，答辩时很容易被评委几句话问住——需求是什么？为什么需要这些页面？数据是怎么流转的？所以一开始就要先理解业务。
老年人生活管理系统对应的现实场景，通常是社区养老服务中心或日间照料中心。服务中心要管理一批老人信息，组织日常活动，记录健康数据，还要处理订餐、保洁、维修这类生活服务请求。在没上系统之前，这些工作大多靠表格和口头沟通，容易出现信息孤岛：今天搞了一场健康讲座，报名了谁来没来没有记录；老人的血压数据散落在一张张纸上，家属无法及时了解。这个系统要解决的核心问题，就是把“人员管理—健康记录—活动参与—生活服务”这四件事串起来，形成在线闭环。
搞清楚这一点之后，技术层面就有的放矢了：这是一个典型的信息管理系统，B/S架构，后端提供接口，前端操作页面，数据库存储关系数据。SSM这套技术栈做这个场景完全够用。
1.2 三种角色的功能边界，决定了系统设计的成败
我实际做这套系统时，把角色分成了三类：管理员、老人、家属。这个划分不是我拍脑袋定的，是从业务场景里推导出来的。
| 角色 | 登录端 | 核心功能 |
|---|---|---|
| 管理员 | 后台 | 老人档案维护、健康记录管理、活动发布与报名审核、生活服务订单处理、数据统计 |
| 老人 | 前台 | 查看个人档案、健康数据、活动大厅浏览、活动报名、提交生活服务申请 |
| 家属 | 前台 | 绑定老人、查看老人的健康记录和活动参与情况 |
这样划分之后，每个页面的菜单和按钮就很好推导了。比如老人登录后，权限范围内只有“我的档案”“健康记录”“活动大厅”“我的报名”“申请服务”，绝不会出现“用户管理”“数据字典维护”这类后台功能。很多同学做这个系统容易翻车，问题恰恰出在功能堆叠——一个页面上既有老人信息表格，又有活动管理按钮，评委问一句“这个操作对应的角色是谁”，当场答不上来。
1.3 给需求做减法：先把主流程跑通
毕设不是商业项目，没必要追求功能大全。我的建议是功能优先级按下面这个顺序来做：
- 登录与权限：不同角色跳转不同首页，这是系统的门面。
- 老人档案管理：增删改查，支持姓名、性别、年龄段等条件筛选。
- 健康记录管理：血压、血糖、心率等指标的新增和查询。
- 活动发布与报名：管理员发活动，老人报名，名额控制，防止重复报名。
- 基础统计报表：老人性别比例、年龄段分布、活动参与数量。
像在线聊天、智能手环对接、在线问诊这类功能，如果没有十足的把握，不建议写进开题报告。主流程顺畅、演示干净利落，比功能数量更能拿分。
2. SSM到底怎么分工：从框架原理到开发环境
2.1 三层职责，用生活类比讲清楚
既然题目带“SSM“三个字母，面试和答辩时必然会被问：“这三个框架分别负责什么？”要能用自己的话讲明白，而不是背定义。
Spring是核心容器，干的是对象管理的活。Service、Dao、Controller这些实例以前要自己new，现在一律交给容器创建，依赖关系也由容器注入。这就好比单位里的后勤部，各部门申请物资不用自己跑市场，后勤统一配发、统一登记，省去大量重复工作。
SpringMVC是Web层框架，接收浏览器发来的请求，解析参数，调用Service，再把结果返回给视图或JSON。它相当于前台接待，客人来了先登记需求，引导到对应部门，然后再把处理结果回复出去。
MyBatis是持久层框架，负责SQL操作。我们可以把SQL写在XML文件里或注解里，对象和数据库字段之间的映射由它来处理。它更像仓库管理员，手里拿着出入库单，说拿货就拿货，说入库就入库。
三个框架的分工，说白了就是：前端接待（SpringMVC）、后勤调配（Spring）、仓库存取（MyBatis）。
2.2 版本搭配与字符集设置
版本搭配是SSM项目最容易踩坑的地方。我自己用过的组合，推荐下面这一套，稳定兼容：
| 组件 | 推荐版本 | 备注 |
|---|---|---|
| JDK | 1.8 | 和旧生态兼容性最好 |
| Maven | 3.6.x | 管理依赖足够 |
| MySQL | 5.7 或 8.0 | 5.7对驱动兼容性更好 |
| Tomcat | 8.5 或 9.0 | 8.5最常用 |
| Java IDE | 任选 | 建议装Lombok插件 |
统一字符集这件事，一定要在创建工程时就定死：JSP页面用UTF-8，数据库连接URL带上useUnicode=true&characterEncoding=utf8，MySQL建表时使用utf8mb4。别小看这一步，后期中文乱码问题十有八九是从这里埋下的。
2.3 工程初建：核心配置与第一个能响应的页面
搭建SSM项目的基本流程是：创建Maven Web工程，引入Spring、SpringMVC、MyBatis相关依赖，配置web.xml，再分别写spring.xml和spring-mvc.xml，以及MyBatis整合配置。我挑最关键的web.xml片段说明。
<!-- 加载Spring容器 --> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <!-- 前端控制器 --> <servlet> <servlet-name>dispatcher</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcher</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>注意servlet-mapping的url-pattern。如果写成*.do，SpringMVC确实能处理以.do结尾的请求，但静态资源JS、CSS、图片全部失效，还得额外配置资源映射。直接写成/，再配合mvc:default-servlet-handler，静态资源问题会省心很多。
3. 数据库建模：老年人业务场景下的表结构细节
3.1 几张核心表，理清业务主线
老年人生活管理系统虽然功能看着多，但数据库核心表也就六张左右：
- user表：存放登录账号、密码、角色类型、姓名、手机号。
- elder_profile表：老人档案，包含姓名、性别、出生日期、身份证号、紧急联系人、住址、自理能力。
- health_record表：健康记录，包含老人ID、测量日期、收缩压、舒张压、心率、血糖、备注。
- activity表：活动表，包含活动名称、类型、开始时间、地点、人数上限、状态。
- sign_up表：报名表，关联活动ID、老人ID、报名时间。
- service_order表：生活服务工单，包含服务类型、内容、老人ID、处理状态。
这六张表基本覆盖题目里所有功能点。先想清楚表关系，再去写Mapper，会顺利得多。
3.2 建模时的几个实用细节
第一，出生日期和年龄不要都存。年龄会逐年变化，每年要批量更新；出生日期是固定值，页面要显示年龄时，用SQL的TIMESTAMPDIFF计算即可。
第二，状态字段统一使用int类型。比如活动状态：0-未开始，1-进行中，2-已结束。数据库里全是数字，翻译成中文的逻辑放在Java枚举或前端字典里，扩展状态不需要改表和SQL。
第三，老人档案要加软删除字段。老人离院或注销后，健康记录、报名记录还需要保留，不能物理删除。加一个is_deleted字段，默认0，删除时改为1，查询时统一过滤。
第四，身份证号不要明文展示。列表页出现完整身份证号既没必要，也不安全。查询出来后用Java截取或加密展示，只保留前6位和后4位。
3.3 建表SQL示例与关联关系验证
下面这份SQL可以直接拿去做改动。elder_profile是老人档案核心表，health_record是健康记录表。
CREATE TABLE elder_profile ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, gender TINYINT NOT NULL COMMENT '0女 1男', birth_date DATE, id_card VARCHAR(64), phone VARCHAR(20), address VARCHAR(200), emergency_contact VARCHAR(50), self_care_level TINYINT DEFAULT 0 COMMENT '0自理 1半自理 2不能自理', is_deleted TINYINT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='老人档案表'; CREATE TABLE health_record ( id INT PRIMARY KEY AUTO_INCREMENT, elder_id INT NOT NULL, measure_date DATE NOT NULL, systolic INT COMMENT '收缩压', diastolic INT COMMENT '舒张压', heart_rate INT COMMENT '心率', blood_sugar DECIMAL(5,2) COMMENT '血糖', remark VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_elder (elder_id), CONSTRAINT fk_health_elder FOREIGN KEY (elder_id) REFERENCES elder_profile(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='健康记录表';活动报名表需要额外注意。报名关系发生在activity和elder_profile之间，我见过很多同学直接设计成在活动表里存一个“报名老人ID”的字符串字段，用逗号拼接。这种方案最大的问题是统计报名人数极其痛苦，连查“谁报名了某活动”都要写拆字符串的逻辑。正确的做法是单独一张关联表，每行一条报名记录。
4. 核心功能实现：身份认证、健康档案与活动报名
4.1 登录会话与拦截器：用一套代码控制页面跳转
系统的第一道关卡是登录鉴权。做法不复杂：登录成功后把当前用户对象放进Session，写一个拦截器，在请求进入Controller之前校验Session是否为空，为空就重定向到登录页。
拦截器的核心代码大概长这样：
public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object loginUser = request.getSession().getAttribute("LOGIN_USER"); String uri = request.getRequestURI(); if (loginUser == null && !uri.endsWith("/login") && !uri.contains("/static/")) { response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }在spring-mvc.xml里注册这个拦截器，拦截/**，再放行登录页和静态资源。实际使用时要根据自己项目的URL前缀微调逻辑。拦截器最大的好处是一旦写好，后面新增的Controller天然受到登录保护，不用每个方法都写Session判断。
4.2 健康档案模块：别把CRUD做成“无脑插入”
健康档案表面上是单表增删改查，但老年人健康数据有几个约束必须处理。以血压为例，收缩压正常范围一般在90到140之间，舒张压在60到90之间。前端表单可以做范围校验，但后端Service必须再做一次，因为接口可以被绕过，也可能被其他系统直接调用。
if (systolic < 60 || systolic > 200) { return Result.error("收缩压数值超出合理范围，请重新测量确认"); } if (diastolic < 40 || diastolic > 130) { return Result.error("舒张压数值超出合理范围，请重新测量确认"); }更扎实的做法是，在Service里先根据elder_id确认老人存在且未删除，再做数值校验，最后插入记录。这样既保证数据完整性，又给代码增加了可讲的业务逻辑。答辩时如果被问到“你这套代码跟仓库管理系统的CRUD有什么区别”，这个校验逻辑就是答案之一。
4.3 活动报名模块：防止重复报名的两种手段
活动报名是典型的一对多关系，一个活动可以被多个老人报名，一个老人也能报名多个活动。最容易出问题的场景是：老人点击“报名”按钮时网络卡顿，连续点了两次，后端收到两个请求，生成了两条报名记录。
我用了两层防护。第一层是数据库唯一索引：
ALTER TABLE sign_up ADD UNIQUE KEY uq_elder_activity (elder_id, activity_id);第二层是在Service里先查后插，捕获重复键异常后返回友好提示。
try { signUpMapper.insert(record); return Result.success("报名成功"); } catch (DuplicateKeyException e) { return Result.error("您已报名过该活动，请勿重复提交"); }有这两层保护，演示时故意快速双击按钮，也不会出现脏数据。这个小细节在答辩现场非常讨喜，评委一看就知道你考虑过并发问题。
4.4 统一响应体与全局异常：让前后端协作不再手忙脚乱
和纯JSP项目不同，当前面的页面用Ajax请求后端时，接口最好统一返回格式。我封装了一个Result对象，包含code、message、data三个字段。所有Controller方法都返回这个类型，前端根据code判断成功还是失败。
再配合@ControllerAdvice处理全局异常，后端一旦抛出未捕获异常，返回给前端的是“系统繁忙，请稍后再试”，而不是一段Tomcat错误页面。这样界面始终友好，排查日志时也能准确定位。
5. 联调期的三块绊脚石：乱码、扫描失效和回显异常
5.1 控制台和页面中文乱码
乱码问题的根源往往是三处不一致。JSP页面编码要是UTF-8，打开jsp文件检查pageEncoding="UTF-8"；Tomcat连接器要支持URIEncoding，在server.xml的Connector里加URIEncoding="UTF-8"；数据库连接URL要带useUnicode=true&characterEncoding=UTF-8。三处只要有一处不一致，就可能出现查询出来的中文正常、插入进去的中文乱码这类奇怪现象。排查时先看数据库表本身的字符集，再一条条检查这三处。
5.2 调用Mapper方法时报 invalid bound statement 错误
这个报错几乎每个SSM项目都会遇到。错误提示是没有绑定到SQL语句，常见原因有四个：Mapper接口和XML文件不在同一个包里；接口方法和XML里statement的id对不上；XML文件没有被Maven编译进classes目录；spring.xml里没有配置mapper-locations。
排查顺序也按这四个来：先看XML是否存在且命名正确，然后确认接口方法名和XML的id一致，再看target目录里有没有XML文件，最后检查mybatis配置的mapper-locations是否指向classpath:mapper/*.xml这类路径。这个错误本身不难解决，但如果不理解配置之间的关联，很容易反复踩。
5.3 编辑回显数据格式不对与JSON序列化问题
编辑老人档案时，出生日期从Date类型传到前端，经常出现一段很长的数字或“Tue Jan 05 00:00:00 CST 2021”这种英文格式。解决办法是在实体类的日期字段上加@JsonFormat(pattern="yyyy-MM-dd", timezone="GMT+8")，或者在返回前手动格式化。
JSON序列化还会遇到循环引用问题。如果老人对象包含List，活动对象又包含报名列表，序列化时可能出现$ref循环引用标记。这种情况一般通过设计VO类解决——不要直接把实体类作为接口返回对象，而是创建视图专用的DTO，只放前端需要的字段。虽然多写几个类，但接口清晰，也不容易泄漏多余数据。
6. 演示录像录制与答辩准备
6.1 录像顺序与录制细节
一份好的演示录像，顺序比画质重要。我建议按这个流程录：
- 管理员登录，展示老人档案列表，做一次新增老人操作。
- 管理员发布一个活动，设置人数上限。
- 老人用户登录，在活动大厅看到新活动，点击报名。
- 切回管理员，打开该活动的报名列表，确认报名记录出现。
- 家属用户登录，查看绑定老人的健康记录和报名信息。
- 最后展示统计报表，导出或截图展示图表。
这个顺序实际上演示了一个完整的业务闭环：管理员创建业务→老人参与→家属查看。评委看录像最怕看到零散功能点的堆砌。录制时把窗口分辨率固定，鼠标移动慢一点，点击后停顿两秒再操作，方便评委看清每一步。录屏工具用任意开源录屏软件都可以，电脑内存不足时先关掉无关程序，避免录制卡顿。
6.2 项目报告与答辩PPT的内容组织
答辩PPT控制在10到12页比较合适：选题背景、需求分析、功能模块图、数据库设计、技术架构、核心功能截图、演示要点、总结与展望。不要放整屏代码，评委更想看到你对系统整体结构的理解。
评委高频问题基本就这几个：SSM的IoC和AOP是什么意思？登录拦截器原理是什么？为什么选MyBatis而不是Hibernate？如何解决重复报名？表之间的关联关系是什么？这些问题在最终写毕业论文时就要准备好，不要临时抱佛脚。每个问题都要结合自己项目的真实实现回答。
6.3 系统还能怎么扩展
如果想把项目做出亮点，我有几个经过验证的扩展方向：用ECharts在后台首页展示老人年龄段分布和活动报名趋势；在活动管理里增加Excel批量导入功能，一次性导入历史活动数据；给健康记录模块增加PDF导出，方便家属打印；热门活动列表用Redis缓存，减少数据库压力。这些扩展都要真正实现过再写进文档，不然答辩现场一旦被要求演示，就会露馅。
做完这套系统，我自己最大的体会是：毕业设计的难点从来不在技术本身，而在于能不能把业务需求讲清楚、把数据模型理顺、把代码和文档对应上。老年人生活管理系统这个题目，看着普通，但只要把角色权限、健康数据、活动报名这几个核心点做扎实，就是一份不输给花哨题目的答卷。最后分享一个小建议：拿到任何源码，都要先跑通，再逐行读，最后自己动手改。只有真正改过一个功能并让它跑起来，答辩时说话才有底气。
