一、为什么要做这款平台？养老场景的 3 大核心痛点
1.1 护工匹配难：信息不对称，效率低
传统护工招聘依赖 “线下中介、熟人推荐”，家属难辨护工资质（如工龄、技能），护工也难找到合适岗位，导致匹配周期长 —— 据调研，家属平均需 1-2 周才能找到满意护工，护工闲置率高达 30%。
1.2 家属 - 老人沟通不及时：需求响应慢
老人多不熟悉智能手机复杂操作，遇到紧急情况（如身体不适）无法快速联系家属；家属也难实时了解老人状态，只能靠护工口头反馈，信息滞后且易遗漏。
1.3 机构管理乱：数据分散，易出错
养老机构管理 “老人信息、护工排班、商品库存” 靠 Excel 表格，数据分散在不同文件中 —— 比如统计老人消费记录时，需手动合并 “购物车、订单、充值” 数据，耗时且易出错，管理效率极低。
二、技术选型：为什么选 SSM+Android？贴合养老平台的 4 大优势
系统围绕 “操作简单、运行稳定、适配老人使用、开发成本低” 原则选型，技术栈覆盖 “前端 - 后端 - 数据库 - 移动端” 全流程：
| 技术模块 | 具体工具 / 框架 | 选型理由 |
|---|---|---|
| 后端开发 | SSM（Spring+Spring MVC+MyBatis） | Spring 实现业务逻辑解耦，Spring MVC 负责前后端数据交互，MyBatis 简化数据库操作；相比 Spring Boot，SSM 更适合中小型项目，学习成本低，且易维护 |
| 移动端开发 | Android Studio 4.2 + Android 11 | 适配老人常用的安卓手机，界面可设计得 “字体大、按钮大、操作简单”（如减少跳转步骤）；Android 开源免费，开发成本低 |
| 数据库 | MySQL 8.0 | 关系型数据库适合存储 “老人信息、护工资料、订单记录” 等结构化数据，支持事务（如护工接单时同步更新订单状态），且支持多表关联查询（如查询某老人的家属及护工信息） |
| 架构模式 | B/S（后端）+ C/S（移动端） | 管理员通过浏览器（B/S）登录后台管理，操作便捷；老人 / 家属 / 护工通过 Android APP（C/S）使用，无需频繁打开浏览器，更符合移动端使用习惯 |
三、系统设计：从 “角色权限” 到 “数据库” 的全链路规划
3.1 核心角色与功能：覆盖四方需求
系统严格划分 “老人、家属、护工、管理员” 四大角色，每个角色功能聚焦且操作简单，避免老人因功能复杂望而却步。
3.1.1 各角色核心功能
| 角色 | 核心功能 |
|---|---|
| 老人 | 查看招聘信息（找护工）、发送私信给家属、管理收藏（如收藏心仪护工）、购物车下单、查看订单 |
| 家属 | 发布护工招聘（填写老人年龄、工作内容、薪资）、私信老人、查看护工资料并评论、给老人账号充值 |
| 护工 | 查看招聘信息并接单、管理个人资料（上传头像、填写工龄）、查看订单（如商品配送进度） |
| 管理员 | 管理老人 / 家属 / 护工信息（新增 / 修改 / 删除）、审核护工资质、管理商品分类与库存、处理订单发货 |
3.1.2 关键流程示例：护工招聘与接单
- 家属登录 APP→进入 “招聘信息” 模块→填写 “老人姓名、年龄、主要工作（如日常陪护）、薪资待遇”→提交发布；
- 护工登录 APP→查看招聘列表→筛选符合条件的岗位（如 “薪资 5000+、工作地址在本地”）→点击 “申请”；
- 家属收到申请通知→查看护工资料（工龄、评论）→确认录用，系统同步更新订单状态为 “已接单”。
3.2 数据库设计：核心表结构详解
基于 “用户 - 内容 - 交互” 三大核心实体，设计 18 张关键表，确保数据关联清晰、存储规范：
| 表名 | 核心字段 | 作用 |
|---|---|---|
laoren（老人表） | id（主键）、laorenzhanghao（老人账号）、laorenxingming（老人姓名）、jiashuzhanghao（家属账号）、money（余额） | 存储老人基础信息，关联家属账号，方便家属管理老人账号余额 |
jiashu（家属表） | id（主键）、jiashuzhanghao（家属账号）、jiashuxingming（家属姓名）、laorenzhanghao（老人账号） | 存储家属信息，与老人表一对一关联，确保家属仅能操作关联老人的数据 |
hugong（护工表） | id（主键）、hugongzhanghao（护工账号）、hugongxingming（护工姓名）、gongling（工龄）、sfsh（是否审核） | 存储护工资料，管理员需审核通过后护工才能接单，保障资质可靠 |
zhaopin（招聘信息表） | id（主键）、jiashuzhanghao（家属账号）、laorenzhanghao（老人账号）、zhuyaogongzuo（主要工作）、xinzidaiyu（薪资待遇） | 存储家属发布的招聘信息，关联家属和老人账号，护工可查看并申请 |
laoren_sixin（老人私信表） | id（主键）、jiashuzhanghao（家属账号）、laorenzhanghao（老人账号）、sixin（私信内容）、shijian（时间） | 存储老人与家属的私信记录，支持历史消息查看 |
shangpinxinxi（商品信息表） | id（主键）、shangpinmingcheng（商品名称）、price（价格）、kucun（库存）、xiangqing（详情） | 存储养老相关商品（如轮椅、保健品），支持老人 / 家属下单购买 |
四、核心功能实现：代码与界面展示
4.1 后端核心接口：以 “护工招聘发布” 为例
用 SSM 框架编写接口，实现家属发布招聘信息的完整流程，包含 “参数校验、数据存储、权限控制”：
// 招聘信息Controller
@Controller
@RequestMapping("/zhaopin")
public class ZhaopinController {
@Autowired
private ZhaopinService zhaopinService;
// 家属发布招聘信息
@RequestMapping("/add")
@ResponseBody
public Map<String, Object> addZhaopin(Zhaopin zhaopin, HttpSession session) {
Map<String, Object> result = new HashMap<>();
// 1. 校验登录状态（仅家属可发布）
Jiashu jiashu = (Jiashu) session.getAttribute("jiashu");
if (jiashu == null) {
result.put("success", false);
result.put("msg", "请先登录家属账号");
return result;
}
// 2. 关联家属账号和老人账号
zhaopin.setJiashuzhanghao(jiashu.getJiashuzhanghao());
zhaopin.setLaorenzhanghao(jiashu.getLaorenzhanghao());
zhaopin.setSfsh("否"); // 初始状态：未审核
zhaopin.setAddtime(new Date());
// 3. 存储数据
zhaopinService.insertZhaopin(zhaopin);
result.put("success", true);
result.put("msg", "招聘信息发布成功，等待管理员审核");
return result;
}
}
4.2 移动端关键界面展示
4.2.1 老人端 - 私信界面
- 界面设计 “大字体、大按钮”，老人点击 “发送私信” 按钮，弹出输入框（字体大小默认 20 号），输入内容后点击 “发送”，实时同步给家属；
- 私信列表按 “时间倒序” 排列，未读消息标红提示，避免老人遗漏重要信息。
4.2.2 家属端 - 招聘发布界面
- 表单字段简化为 “老人姓名、年龄、主要工作、薪资待遇、联系电话”，必填项标 “*”，减少填写负担；
- 下拉选择 “主要工作”（如 “日常陪护、康复护理”），无需手动输入，降低操作难度。
4.2.3 管理员端 - 护工审核界面
- 表格展示 “护工账号、姓名、工龄、提交时间”，审核通过则设置 “sfsh = 是”，护工可正常接单；审核不通过则填写 “审核回复”（如 “需提供健康证明”），系统同步通知护工。
4.3 系统运行截图
五、系统测试：3 大维度验证可用性
5.1 功能测试：覆盖核心场景
通过 “测试用例” 验证功能是否符合养老场景需求，关键测试场景如下：
| 测试功能 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|
| 老人发送私信给家属 | 家属 APP 收到消息提示，私信列表显示新消息 | 家属实时收到提示，消息正确显示 | 成功 |
| 家属发布护工招聘 | 管理员后台可查看待审核招聘，审核后护工可见 | 招聘信息正常进入审核流程，护工端可查看 | 成功 |
| 护工申请岗位 | 家属收到申请通知，可查看护工资料 | 家属实时收到通知，护工资料完整展示 | 成功 |
| 管理员审核护工资质 | 审核通过后护工可接单，不通过则收到回复 | 审核状态同步更新，护工收到对应通知 | 成功 |
5.2 易用性测试：适配老人操作习惯
邀请 10 位 60-75 岁老人参与测试，重点验证 “界面操作难度”：
- 界面字体默认 20 号，按钮尺寸≥48px（符合老人视力和手指操作习惯），90% 老人可独立完成 “发送私信、查看招聘” 操作；
- 减少跳转步骤，如老人从首页到发送私信仅需 2 步（首页→私信→选择家属→发送），无复杂操作。
5.3 稳定性测试：应对多用户并发
用 Jmeter 模拟 “50 人同时登录、20 人同时发布招聘”，测试结果如下：
- APP 响应时间≤1.5 秒，无卡顿；
- 数据库无数据丢失，如护工同时申请同一岗位时，系统正确处理 “先到先得” 逻辑，无重复接单情况。
六、总结与优化方向
6.1 项目总结
这款平台通过 “SSM 后端 + Android 前端”，解决了养老场景 “护工匹配难、沟通不及时、管理乱” 的问题，实现了 “四方角色协同”—— 老人操作简单、家属沟通便捷、护工接单高效、管理员统筹有序，核心功能完全满足中小型养老机构或家庭的智慧服务需求。
6.2 未来优化方向
- 新增 “健康监测” 功能：对接智能手环，实时同步老人心率、血压数据，异常时自动通知家属和管理员；
- 优化护工评价体系：增加 “服务评分、服务时长” 排序，家属可优先选择高评分护工，提升匹配质量；
- 适配老人专属操作：添加 “语音输入” 功能（老人可语音发送私信）、“一键呼救” 按钮（紧急情况快速联系家属），进一步降低操作门槛。
七、附：核心资料获取
完整开发资料包含：
- 后端源码（SSM 框架配置、Controller/Service/DAO 层代码、MyBatis 映射文件）；
- Android 前端源码（界面布局 XML、Activity 逻辑、网络请求封装）；
- 数据库脚本（创建表 SQL、测试数据 SQL）；
- 测试用例文档（功能测试、易用性测试详细步骤）。
👉 关注博主，查看置顶文章，可获取平台相关技术文档与核心代码，助力养老类项目开发或毕设落地。
如果本文对你的 SSM 开发、养老平台设计有帮助，欢迎点赞 + 收藏 + 关注，后续会分享更多贴近实际场景的开发案例！
