基于个性化智能提醒的社区老年康养管理系统实战解析

选毕设题目这件事，我见过太多人卡在同一个地方：题目太"水"怕答辩被老师一句"这不就是个增删改查吗"怼到哑口无言，题目太难又怕做到一半直接崩溃换题。如果你正在Java方向上摇摆，这个"基于个性化智能提醒的社区老年康养管理系统"确实值得认真看一眼。它不是那种常见的图书管理、学生管理套路题，而是踩中了两个非常实在的点：一是养老这个社会真实需求，业务场景成立；二是"个性化智能提醒"这个功能点，足够你讲出一套有逻辑的技术故事，而不是只会说"我写了CRUD"。

这篇文章我会把这个题目的底层逻辑、系统怎么拆、核心的提醒模块怎么设计、落地时有哪些坑、以及答辩和简历上该怎么包装，一次性讲透。不管你是刚学完Spring Boot想做点像样的东西，还是已经被导师催着交开题报告，按这个思路走，心里会踏实很多。

1. 这个选题为什么值得做：从毕设痛点说起

1.1 大多数毕设题目的两种"死法"

先聊点真实的。每年毕业季我都能看到两类典型翻车现场。

第一类是"管理系统全家桶"：学生信息管理、图书借阅管理、超市进销存、停车场收费……这些题目不是不能做，问题是太泛滥了。答辩时几个老师一天听一百遍"基于SSH的某某管理系统"，你说你的系统用了Spring Boot、MyBatis Plus，老师点点头，然后问一句："和前年那个用SSH的有什么区别？"你如果答不上来，分数基本就压在及格线上了。

第二类是"宏伟蓝图型"：分布式微服务、秒杀系统、人脸识别考勤、区块链溯源……技术名词堆了一堆，听着特别唬人。问题是毕设周期就那三四个月，你还得写论文，一个人从零搞一套微服务架构，还要保证演示不崩，压力非常大。我见过不少同学十月选了大数据推荐系统，十二月悄悄把题目改回"简单点的小程序"，白白浪费两个月。

这个老年康养系统的聪明之处在于，它刚好卡在两类题目中间——技术上不冒进，业务上不空洞，有一个明确的功能亮点可以支撑起整个项目的深度。

1.2 老年康养选题的三层优势

先说业务层面。社区养老是这几年的真实热点，几乎每个城市都在推社区居家养老服务中心。系统里可以有老人档案、健康数据、用药计划、社区活动、家属绑定这些概念，业务是完整且有温度的。答辩时你不需要跟老师解释"这个系统解决什么痛点"，因为答案就在题目里：老年人容易忘事、需要被提醒、需要家人和社区关注。这不是你做出来的伪需求，是真实社会问题。

再说技术层面。Spring Boot + MySQL是Java Web开发的标准组合，稳定、好调试、资料多。做这个题目的整体技术难度是中等偏下的，但又有足够空间让你展示：定时任务、消息推送、WebSocket、JWT鉴权、接口设计、数据库表关系设计……每一块都是面试和答辩中实打实会被问到的内容。你可以根据自己水平做加法或减法，这个弹性很重要。

最后是延展层面。这个题目的"提醒"功能天然带有智能化的味道。你在论文里可以写出"基于规则的个性化提醒策略""提醒优先级计算模型"这样的章节，听起来有水平，实现起来又不是天方夜谭。如果你还有余力，甚至可以接入简单的算法或者开放接口，把它升级成一个有自己的技术壁垒的作品——这一点对想冲高分或者想拿它找工作的同学来说特别关键。

1.3 哪些人适合拿这个题目

说实话，这个题目几乎适合所有Java方向的本科生，但要分人群说清楚。

• 基础一般的同学：只做基础模块，老人信息维护、健康记录录入、公告发布，再配一个"用药提醒"的小定时任务，就足够完整了，工作量在可控范围内。
• 基础中等的同学：把个性化提醒做深，加上家属端、健康数据趋势图表、提醒规则的灵活配置，系统完成度会明显更高。
• 基础较好、想冲高分的同学：可以在提醒策略里引入优先级评分模型，用Redis做热点数据缓存，用WebSocket做实时消息推送，再用Docker把环境一打包，项目的技术含量直接上一个台阶。

选这个题目不亏。因为无论你最后做成什么深度，它都不会在选题层面给你拖后腿。

2. 系统功能地图：别一上来就写代码，先把业务切清楚

很多同学做毕设最容易犯的一个错误：拿着题目就去建表、写接口，写到一半发现功能对不上、数据乱七八糟，回头再改设计，一来一回两周没了。做这个系统，我强烈建议你先花两三天时间把功能边界划明白。

2.1 四大端口的职责划分

社区老年康养系统虽然叫"社区"，但使用者绝对不只是社区管理员一方。按我的经验，至少要有四个入口，职责不能混。

四个端口的划分不只是为了界面上的角色区分，更关键的是它决定了你的数据权限设计和API设计。比如家属端只能看自己绑定的老人数据，护工端只能处理分配给自己的工单，这些在数据库层面就要有明确的归属关系，不然后面做接口时会特别痛苦。

这里多说一句，很多同学以为"管理端+用户端"就够用了，实际上一套系统如果只有两个角色，答辩时老师很容易追问"那护工和家属用什么"，逻辑上说不圆。四个端口虽然开发量上去了，但业务故事完整，论文也好写。

2.2 核心业务流转：一条提醒的完整生命周期

这个系统的业务主线和别的管理系统不一样，它不只是一堆数据的增删改查，而是围绕"提醒"这个动作展开的。我建议你把主流程吃透，而不是急着写代码。

举个具体的例子。一位老人叫张阿姨，她患有高血压，每天上午8点要吃降压药，每周二上午要去社区量一次血压，每周五下午社区有书法课，她报名参加了。

在系统里，这条业务链是这样跑的：

1. 管理员或家属在老人档案中录入"张阿姨"的基础信息和慢病标签（高血压）。
2. 家属在用药计划中给张阿姨创建一个"降压药"计划，每天一次，上午8点。
3. 系统根据"用药计划"自动生成一条提醒规则：每天8点提醒张阿姨吃药。
4. 定时任务每分钟扫描一次，发现有"到点且未完成"的提醒，就推送给老人端和家属端。
5. 张阿姨在老人端点击"确认已服药"或者家属反馈"已确认"，提醒状态变为完成。
6. 如果张阿姨连续3次未确认服药，系统给家属和管理员发送"异常预警"。
7. 系统在月末生成一份健康报告，包含服药达标率，供管理员和家属查阅。

你注意看，这个流程里涉及的就不只是"提醒表"这么简单了，而是提醒规则、提醒记录、健康数据、异常预警、统计报表一整套数据流转。把这个故事讲清楚，你的系统设计和论文框架就已经立住了一半。

2.3 数据库表怎么设计才不返工

建表是许多同学翻车的第一站。我见过太多人把"提醒"直接设计成一张大宽表，结果到后面扩展提醒类型时完全动不了。合理的表结构应该把"规则"和"执行记录"分开。

核心表可以这样规划：

• elderly_user：老人基础档案，字段包括姓名、年龄、联系方式、家属联系方式、慢病标签、健康等级、居住地址。注意要有"紧急联系人"独立字段，这是业务的硬需求。
• family_relation：老人与家属的绑定关系表，因为一个老人可能有多个家属，一个家属也可能绑定多个老人，多对多关系需要中间表。
• health_record：健康测量记录，包括血压、血糖、心率、体重等指标，关联elderly_user。
• medication_plan：用药计划，记录药名、剂量、服用频率（每天几次/每周几次）、服用时间点。注意"频率"和"时间点"要用合适的字段表达，建议用JSON数组存"每周一、周三的8:00"，而不是直接用枚举写死。
• reminder_rule：提醒规则表，这是整个系统的核心。字段包括老人ID、提醒类型（用药/测量/活动/预约）、触发规则描述、关联业务表ID、提醒文案模板、是否启用。规则独立于业务数据，是"个性化"的关键。
• reminder_log：提醒流水表，每生成一条提醒就记录一行，包含老人ID、规则ID、计划触发时间、实际发送时间、状态（待确认/已完成/已忽略/已超时）、确认人。
• activity_info / activity_signup：社区活动与报名表，活动包含时间、地点、名额、报名截止时间。
• notice_info：系统通知公告表，用于站内信/公告栏。
• sys_user：系统用户表，包含管理员、护工、家属等不同角色的账号信息，用角色字段区分。

这套表结构的关键设计思想是：把"老人业务数据"、"提醒规则"和"提醒记录"三层分开。这样以后业务数据变了，比如老人换药了，我只需要把用药计划的时间改了，提醒规则跟着变，历史提醒记录仍然完整保留，数据可追溯。这一条在答辩时可以主动讲给老师听，很容易加印象分。

3. 个性化提醒模块：这个项目的灵魂

说实话，这个系统里老人档案、健康记录、活动报名这些模块，任何一个有CRUD经验的同学都能做，真正拉开差距的是提醒模块。题目里专门加了"个性化智能提醒"六个字，这就是你整个项目的内核。这一部分我会拆开揉碎讲。

3.1 所谓"个性化"到底指什么

先说一个很容易踩的坑：很多人把"个性化"理解成"用户可以自定义设置提醒时间"。这不算错，但太浅了。真正的个性化应该是系统基于老人的不同情况自动生成不同的提醒策略。

我的理解是三个层级：

**第一层：基于老人基础属性的差异。**张阿姨有高血压，所以要提醒她每天量血压；李大爷有糖尿病，所以不用提醒他量血压，但要提醒他测空腹血糖。老人的慢病标签决定了提醒内容。

**第二层：基于近期行为数据的动态调整。**如果张阿姨最近三天血压都偏高，系统应该自动增加提醒频率——比如把"每周提醒量一次血压"加强为"每天提醒一次，并给家属发送一条关注提示"。这就是数据驱动的智能化，而不是简简单单的定时触发。

**第三层：基于时间偏好和重要程度的优先级。**有人习惯早上8点看到所有提醒，有人喜欢提前一天收到活动通知。系统可以通过老人端的一个简单设置（或者管理员配置）来调整提醒偏好，同时在一条时间线上把紧急提醒（如服药）置顶。这个看似简单，但很体现"为用户考虑"的产品思维。

这三层不用全做，但你在设计和论文里要能讲出这个层次感，答辩时老师问"你哪里个性化"时，你回答的就不再是"我能设时间"这种一句话，而是一整套策略。

3.2 规则引擎式提醒的落地逻辑

我这几年跟不少做物联网、做告警系统的朋友交流，发现成熟的提醒类系统几乎都是"规则引擎"的思路——把"什么条件下触发什么动作"配置化，而不是把逻辑写死在代码里。

放到这个毕设里，落地方式可以这样设计：

java复制// 提醒规则实体（简化版）
public class ReminderRule {
    private Long id;               // 规则ID
    private Long elderlyId;        // 老人ID
    private String ruleType;       // 提醒类型：MEDICATION/HEALTH/ACTIVITY/APPOINTMENT
    private Integer priority;      // 优先级：1紧急 2较高 3普通 4低
    private String cronExpr;       // 或 触发时间表达式，如 "0 0 8 * * *" 表示每天8点
    private String contentTemplate; // 提醒文案模板，如："您该服用{0}了，请按时服药"
    private String actionChannel;   // 推送渠道：APP/SMS/站内信
    private Integer status;         // 启用/停用
    private Date createTime;
}

业务中如何使用这套规则？核心流程是：定时任务扫描规则表 → 判断当前时间是否到触发点 → 检查老人是否有未完成的同类型提醒（防重复） → 生成提醒记录 → 推送到目标渠道。

这里有个重要的设计细节：提醒规则要跟具体的业务表（用药计划、健康计划、活动报名）做关联。更合理的做法是，在执行业务操作时触发规则的自动生成——家属创建一个用药计划，系统就自动生成一条对应的提醒规则；老人取消活动报名，系统就停用那条活动规则。这样不用人工去维护"提醒配置"和"业务数据"两套东西，一致性才能保证。

java复制// 规律动作：创建用药计划时自动生成提醒规则
public void createMedicationPlan(MedicationPlan plan) {
    medicationPlanMapper.insert(plan);
    // 自动生成提醒规则
    ReminderRule rule = new ReminderRule();
    rule.setElderlyId(plan.getElderlyId());
    rule.setRuleType("MEDICATION");
    rule.setCronExpr(buildCronFromPlan(plan));
    rule.setContentTemplate("您该服用{0}了，请按时服药。");
    reminderRuleMapper.insert(rule);
}

有些同学会用一种偷懒的做法：在mapper层写一个查询"当前所有需要提醒的老人"，然后把提醒内容硬编码在Service里。这种做法表面能用，但一旦老人换药、改时间、换频率，代码里一大片if-else就全乱了。规则引擎的思路核心是"数据驱动"，你把这个思想在论文里讲透，已经是高分内容了。

3.3 提醒优先级：不骚扰、不遗漏

一个好的提醒系统不能只是"到点就发"，还要能判断"现在该不该打扰老人"。这里我提供一个可以实现的计算模型，不会太难，但对项目深度有很大提升。

给老人维护一个实时"关注优先级分"，比如：

• 基础分60：所有老人都有。
• 慢病标签：高血压+5，糖尿病+5，心脏病+10，行动不便+5。
• 近期健康指标异常：一项异常+3，三项连续异常+10。
• 近期漏服/未确认记录：每次未确认+2。
• 年龄因素：80岁以上+5，70-80岁+3。

然后约定评分阈值：75分以上为"重点关注"，65到75分为"需关注"，65分以下为"常规关注"。不同等级对应不同的提醒频率和推送渠道。

java复制public int calcAttentionScore(Long elderlyId) {
    int score = 60;
    ElderlyUser user = elderlyMapper.selectById(elderlyId);
    // 慢病标签加分
    int chronicCount = elderlyMapper.countChronicTags();
    score += chronicCount * 5;
    // 近期健康异常加分
    int abnormalCount = healthRecordMapper.countAbnormalLastWeek();
    score += abnormalCount * 3;
    // 近期漏服加分
    long missCount = reminderLogMapper.countMissedByType(elderlyId, "MEDICATION");
    if (missCount > 0) score += missCount * 2;
    // 年龄加分
    if (user.getAge() >= 80) score += 5;
    else if (user.getAge() >= 70) score += 3;
    return score;
}

这个模型利用的是规则引擎里最常见的评分卡思想，引入之后你可以在代码里实现"连续三次未确认服药就给家属发预警"这类逻辑，也可以在页面上给老人卡片标出红黄绿状态。技术不难，但老师看到的时候会觉得"这个项目有脑子"。

3.4 别让提醒变成骚扰：频控与免打扰设计

做提醒功能的人容易陷入一个误区：只要功能通了，就一直发、反复发，结果老人被骚扰得不行。真实项目中，"提醒频率控制"和"免打扰时段"是必须考虑的。

我的建议是至少要做三层控频：

1. 同类去重：如果同一规则在短时间内已生成了一条待确认提醒，不再生成重复提醒。
2. 单日上限：同一个老人每天最多收到X条系统推送（比如10条），超出后只保留紧急级别的提醒。
3. 免打扰时段：21:00到次日7:00，系统只发紧急级别消息，其余消息堆积到早上7点后统一推送。

java复制// 提醒频控：同一老人、同一规则、同一天内去重
private boolean isDuplicate(Long elderlyId, Long ruleId) {
    LocalDate today = LocalDate.now();
    DateTimeFormatter f = DateTimeFormatter.ofPattern("yyyy-MM-dd");
    String start = today.atStartOfDay().format(f);
    String end = today.atTime(LocalTime.MAX).format(f);
    int count = reminderLogMapper.countByElderlyAndRuleAndTimeRange(
            elderlyId, ruleId, start, end);
    return count > 0;
}

这类逻辑写在拦截器或者发送服务里，属于"运营安全"层面的设计。你要在论文里单独作为一个小节写出来，展示你考虑问题不是停留在"能跑"，而是想过"跑得稳、跑得体面"。老师看过的毕设里，一百个里能有两三个写频控逻辑就算不错了。

4. Spring Boot 落地过程中的关键实现与避坑

4.1 项目骨架与依赖选型

技术栈建议直接锁定：Spring Boot 2.7.x + MyBatis Plus + MySQL 5.7/8.0 + Redis（可选）+ Maven。前端可以选Vue或者Thymeleaf，看你的时间安排——时间紧的话用Thymeleaf + Bootstrap最快，时间充裕的话前后端分离能显得更完整。

一个非常实在的提醒：Spring Boot版本不要追求最新。3.x版本对JDK和部分库的兼容要求更高，协会报错会让你排查半天。我用2.7.x已经非常稳，资料也多，出问题随便一搜就有答案。

Maven依赖里几个容易漏的：

xml复制<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-websocket</artifactId>
</dependency>

MyBatis Plus的BaseMapper开箱即用的CRUD可以省掉大量写mapper的时间，毕设阶段用起来非常合适。但注意，自定义复杂查询时还是老老实实写XML或注解SQL，不要硬用Wrapper堆，尤其是多表关联时，Wrapper写法又丑又容易错。

4.2 定时扫描是核心，别被 @Scheduled 坑了

个性化提醒的实现，核心是"定时扫描"。Spring自带的@Scheduled注解足够支撑单机版毕设，用法很简单，但有几个坑值得提前说。

**第一个坑：默认单线程执行。**Spring的@Scheduled默认一个线程跑所有任务，如果你写了多个@Scheduled方法，一个卡住，其他的全排队。手动配置一个线程池能避免很多莫名奇妙的"报错但不执行"问题。

java复制@Configuration
public class ScheduledConfig implements SchedulingConfigurer {
    @Override
    public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
        taskRegistrar.setScheduler(Executors.newScheduledThreadPool(5));
    }
}

**第二个坑：记住了"上一次执行时间"吗？**如果服务在提醒时间点宕机了10分钟再恢复，@Scheduled默认不会补偿这10分钟的提醒，因为它是基于固定间隔触发的。解决方式是：扫描时按"当前时间"去匹配提醒规则，而不是依赖"上次触发时间+间隔"的简单逻辑。我的做法是扫描规则表时判断"当前时间是否落在本周期内且状态为待执行"，这样重启后下一分钟自然补偿，不怕丢。

**第三个坑：分布式环境下的重复执行。**如果你以后上了Docker多实例部署，多个实例同时扫，提醒会重复发送。毕设阶段单机不会遇到，但论文里可以提一句"分布式锁"的解决思路，体现你的架构意识。

扫描的核心逻辑大概长这样：

java复制@Component
public class ReminderScanTask {

    @Scheduled(cron = "0 * * * * ?") // 每分钟执行一次
    public void scanAndSend() {
        Date now = new Date();
        // 1. 查询所有启用的提醒规则
        List<ReminderRule> rules = reminderRuleMapper.selectList(
                new LambdaQueryWrapper<ReminderRule>()
                        .eq(ReminderRule::getStatus, 1));
        for (ReminderRule rule : rules) {
            // 2. 判断当前时间是否命中触发时间
            if (!TimeUtils.isHit(rule.getCronExpr(), now)) continue;
            // 3. 防重复检查
            if (isDuplicate(rule.getElderlyId(), rule.getId())) continue;
            // 4. 生成提醒记录
            ReminderLog log = buildReminderLog(rule);
            reminderLogMapper.insert(log);
            // 5. 推送：站内信 / 短信 / WebSocket
            pushToClient(log);
        }
    }
}

这套逻辑就是整个提醒模块的发动机。你要保证每分钟跑一次时遍历效率够高，数据量在毕设级别不用太担心，但要养成给规则表加索引的习惯，比如status和elderly_id联合索引。

4.3 调试经验和常见报错速查

毕设做Spring Boot项目，遇到报错相当正常，关键是要有条理地排查。我整理了一份这个项目里最高频的五类问题：

调试技巧上也值得多说一句：提醒模块这类定时任务，不适合一遍遍改cron表达式去等时间。我的习惯是写一个手动触发接口（比如 /dev/test/scanReminder），让开发环境可以随时调用扫描逻辑，配合日志在控制台看输出。等逻辑稳定了，再让定时任务接管。这个"开发期手动触发+生产期定时调度"的开关切换思路，在日常开发里也是通用的。

4.4 提醒消息的推送渠道怎么做

很多同学做毕设时默认提醒就是发短信，结果一调研发现短信接口要企业认证、要花钱，项目卡在这里。提醒的落地渠道完全可以选择更可控的方案：

• 站内信/通知公告：存入notice表，老人端和家属端登录后拉取未读消息。这个最简单，用不用都行。
• WebSocket实时推送：老人端和家属端如果是在线状态，服务器可以主动推送提醒到浏览器，体验最像"真移动端通知"。实现不难，Spring Boot整合WebSocket的代码网上很多，关键是前端要自己处理断线重连。
• 短信模拟：如果实在要展示短信的效果，可以用第三方测试平台的测试签名，或者自己写个"短信发送日志"接口，把发送行为记录下来，演示时给老师看"这里调用了短信网关，发送成功后回执存库"。核心是"调用次数、回执状态、失败重试"这一套设计，而不是真的把短信发出去。

我自己做的时候是把三个渠道的接口抽象成一个PushService，内部根据规则配置的actionChannel分发。这个设计不复杂，但答辩时可以讲出"多渠道适配"四个字。

5. 演示数据、答辩亮点与简历包装

5.1 一套让老师"眼前一亮"的演示数据

说个现实问题：很多同学的演示数据是直接用Bean拷贝工具random生成的，姓名乱码、年龄800岁、血压3000，老师一打开表格就笑了。这套系统的演示数据我建议你花半小时手写一份"有故事感"的数据集。

比如：

• 张秀英，72岁，高血压+糖尿病，每天8点需要服药，每周二社区量血压，上周连续三天血压偏高。→ 演示时首页就能看到红色预警卡片，点进去能看到完整的健康趋势图，体现出你系统的"智能"价值。
• 李长福，66岁，行动不便，用轮椅，每周需要上门理疗服务。→ 演示护工的工单列表和上门服务记录。
• 王桂芳，81岁，独居，孩子在外地。→ 演示家属端远距离关联和异常预警推送。

你甚至可以预先操作几步，让系统的"未确认提醒"里躺着两三条数据，演示时当着老师的面点击"确认服药"，然后展示状态流转和日志变化。这个过程比念PPT强十倍。

5.2 答辩前必须想清楚的三个技术问题

我在帮人模拟答辩的时候，发现不管项目多简单，老师总会按这几个角度去问。提前准备，别临场瞎编。

第一个问题："你这个个性化提醒，个性化到底体现在哪？"
这是必问题。你的回答逻辑应该非常清晰：老人基础属性不同→规则不同；健康数据异常→自动升级提醒频率；连续未确认→触达家属。把这三个层次讲出来，谁听了都会觉得你是真做了思考。

第二个问题："如果提醒规则改了一万条，性能怎么办？"
别慌，先说实话：毕设级数据量不会有性能问题。然后补一句："在生产级场景下，我会把规则放Redis做缓存，扫描任务引入消息队列，发送做批量削峰。"你不需要真做出来，但你要让对方知道你有扩展的意识。

第三个问题："这个系统和普通的健康管理App有什么区别？"
这个问题是让你展示业务理解的。区别在于社区属性+角色协同：管理员能管理整个社区的康养服务，护工有一线服务工单，家属有知情权，老人有提醒关怀。这不是一个独立App能覆盖的，它是一套针对社区场景的角色协同解决方案。

5.3 把毕设变成简历项目话术

还在找工作的同学注意了，这个项目的痛点特别好写进简历。不要写"基于Spring Boot的老年管理系统"这种平淡无奇的描述，要写清楚你做了什么、遇到了什么、如何解决。

我推荐这样改：

"该项目面向社区养老场景，设计并实现了包含老人档案、健康监测、用药提醒、活动管理等模块的康养管理平台，核心亮点是个性化智能提醒模块。技术栈采用Spring Boot + MyBatis Plus + MySQL + Redis，通过规则引擎思路将提醒规则与业务数据解耦，实现基于老人慢病标签、健康数据异常和服药确认率的动态评分与优先级提醒。提出并落地了提醒频控与免打扰机制，避免消息骚扰。使用@Scheduled实现定时扫描，并设计了手动触发开关用于开发期联调。"

这段描述里出现了"规则解耦""动态评分""频控""免打扰""定时扫描"，任何一个人事或技术面试官扫到这几组词，都会觉得这个候选人不只是会增删改查。这本来就比"我做过XX管理系统"有竞争力得多。

最后再分享一个实际经验

这几年帮人看过不少毕设，我自己的体会是：选题目时"看起来很多同学都做"不可怕，可怕的是"做完之后自己都说不出这个系统解决了什么问题"。这个老年康养系统赢就赢在每一个模块都有明确的业务出口——提醒是给谁看的、健康数据是给谁用的、预警是给谁发的，每一行代码背后都有使用者。

如果你决定做这个题目，先别急着写代码，花两天把业务剧情梳理清楚，把张阿姨、李大爷这些"用户"的故事讲给自己听，然后再去建表、写接口。你会发现后面所有开发都特别顺，因为你知道自己在为什么而做。祝顺利。