1. 为什么这个题目值得做老年康养赛道里真正有场景的毕设选择每年到了毕设选题季我都能看到大批同学扎堆去做“XX管理系统”——图书管理、学生选课、员工考勤做完发现功能重复率极高答辩时老师一眼就看穿是“增删改查四件套”。而“基于SpringBoot的社区老年康养智能服药提醒管理系统”这个题目从一开始就不是普通的管理系统。先说说为什么这个方向有现实价值。我国老龄化进程很快社区里独居老人、空巢老人越来越多慢性病需要长期服药的比例非常高。但老年人漏服、错服、重复服药的情况非常普遍——不是他们不想按时吃而是记不住、看不清说明书、子女不在身边没人提醒。我认识的一个社区工作者跟我聊过他们做过统计独居老人中超过六成存在不同程度的用药不规范问题其中漏服是最高发的情况。这不是一个“编出来的需求”而是真实发生在每个家庭里的痛点。放到毕设场景里这个题目的优势非常明显第一业务逻辑有深度。“智能提醒”四个字不是硬凑的它涉及定时任务、个性化策略、提醒记录闭环比单纯的增删改查有技术含量答辩时有东西可讲。第二技术栈匹配主流招聘需求。SpringBoot是当前Java后端最主流的框架面试题里Java基础、Spring全家桶、数据库设计都是高频考点。做一个贴合真实需求的项目比做一个纯教学Demo更有说服力。第三赛道加分。智慧养老是政策鼓励的方向康养、社区服务这些关键词天然带有社会价值论文的“研究意义”和“应用前景”这两章特别好写评阅老师也认可这类选题的务实性。第四工程量适中。单人说毕设大概三到四个月周期这个系统可以从单体架构起步核心模块做扎实不需要引入微服务、分布式这些重武器但又比普通管理系统多一条“提醒引擎”的主线深度和完成度都好掌控。这篇文章我就以一个帮同学做了多年毕设调试和定制的视角把这个系统的选型思路、核心设计、提醒引擎的实现逻辑、实际开发中容易踩的坑一条一条捋清楚。文章会配源码和文档的完整交付方案但更重要的是让你真正理解这套系统“为什么这么设计”这样不管是自己开发、二次修改还是答辩讲解你都能说到点子上。2. 功能边界与业务闭环一个提醒管理系统到底长什么样很多同学拿到这个题目后的第一反应是“不就是给老人建个档案然后定时弹个提醒吗”——方向对了但远不止这些。我建议你先把整个业务闭环画清楚然后再动手写代码。这个系统的核心链路是建立用药计划 → 触发智能提醒 → 记录服药反馈 → 异常情况通知家属/护工 → 形成健康记录报表五步形成闭环缺一环系统都不完整。2.1 按用户角色拆解功能模块系统至少要服务四类角色每类角色的界面和权限都不一样角色核心诉求主要功能点系统管理员管理社区整体数据用户管理、药品字典维护、参数配置、数据统计护工/社区工作人员批量管理老人用药老人档案管理、用药计划配置、提醒记录查询、漏服处理老人终端使用者按时获知用药信息接收提醒、确认服药、查看用药说明家属/监护人远程掌握父母用药情况查看提醒反馈、接收漏服通知、查看用药日历这个权限模型用SpringBoot做RBAC基于角色的访问控制非常顺手三张表——用户表、角色表、用户角色关联表——就能支撑起来答辩时还能顺带提一句“基于RBAC的权限设计”这是加分项。2.2 业务模块的详细边界老人档案管理不只是姓名、年龄、联系方式还要包含社区区域、紧急联系人、家属绑定关系、既往病史简述。这些字段后面会关联到提醒策略的个性化配置——比如一个患有糖尿病的老人和一个术后恢复的老人提醒内容的措辞和语音播报语速都应该不一样。药品信息管理建议内置一个药品字典库包含药品名称、通用名、规格、用法、注意事项。老人端或者护工端选药时直接从字典里选避免手输造成的错别字问题。这里有个实操细节同一药品可能会有不同的厂家规格字典设计时要把“药品名称”和“规格”拆开做二级选择。用药计划管理这是全系统的核心数据模型。一张计划表要能表达清楚“谁、在什么时候、吃什么药、吃多少、吃多久、有什么注意事项”。“什么时候”不是简单的一个时间字段而应该是“提醒规则”能支持每天早上8点、每隔12小时、每周一和周四、餐后半小时这类复杂组合。提醒触发引擎定时任务扫描到期计划通过短信接口、小程序模板消息、站内消息或语音播报等渠道触达用户。这个模块我会在第5节专门展开讲是整个系统最值得深挖的技术点。服药反馈与提醒记录老人收到提醒后的操作结果要记录在案——按时服药、误时服药、拒绝服药、漏服未响应。每次提醒本身也要留痕包括提醒时间、渠道、是否成功送达。这两块数据是后续报表统计的基础。异常预警与家属联动老人超过设定时间比如提醒后30分钟未确认服药系统要自动升级处理——先二次提醒再不响应就通知紧急联系人。这个设计在答辩时叫“升级式提醒策略”体现的是系统的人性化考量。数据统计与可视化按周/月统计每位老人的按时服药率、漏服次数、各类药品的服用依从度供社区管理方调整护理策略。用ECharts画折线图和柱状图效果直观也是论文里截图展示的亮点部分。2.3 需求优先级排序先做主干再逐层加枝毕设时间有限我不建议一开始就所有功能平均用力。我的建议顺序是第一优先级必须做老人档案、药品字典、用药计划配置、定时提醒触发、服药反馈记录。这套主链路跑通了系统的“精气神”就有了。第二优先级强烈建议漏服预警通知家属、统计报表。这两个功能开发量不大但让系统从“工具”变成了“平台”论文和答辩展示时能提升一个档次。第三优先级看时间量力而行语音播报提醒、二维码扫码登录、药品余量库存提醒、数据导出Excel。我一直跟同学强调一句话毕设的核心是展示“我完整地解决了一个问题”而不是“我罗列了很多功能”。把主链路做深做透比堆砌五个半成品强得多。3. 技术选型与系统架构为什么是SpringBoot为主干这套系统的技术选型我直接给出推荐方案然后逐项解释理由。技术选型的原则是主流、够用、讲得清、能落地——每个选择都要能在答辩时说出“为什么不用别的”。3.1 后端框架SpringBoot 2.xSpringBoot是目前Java领域事实上的标准框架理由不需要多讲。具体到版本我建议用2.7.x系列原因有两个一是稳定社区资料多遇到问题基本都能搜到解决方案二是3.x虽然已经推出但部分第三方中间件的兼容性和大量老教程还停留在2.x时代毕设期间没必要给自己增加兼容性排查的负担。选SpringBoot还有一个隐藏好处Java面试题里SpringBoot的频率极高做完这个项目你对自动装配、starter机制、配置文件加载顺序、Bean生命周期这些知识点是真正用过一遍的和背面试题的感觉完全不一样。3.2 ORM框架MyBatis-Plus还是Spring Data JPA这两个选哪个都行但我的倾向很明确MyBatis-Plus。原因很简单——开发效率高。BaseMapper里现成的insert、updateById、selectPage、selectList能覆盖80%的常规数据操作你只需要专注写那些复杂查询的XML或注解SQL即可。SpringBoot整合MyBatis-Plus的流程非常成熟网上的配置教程一抓一大把遇到问题不会卡住。3.3 前端方案服务端渲染还是前后端分离这里我强烈建议大部分同学选择服务端渲染Thymeleaf或者轻量前后端分离Vue Element UI而不是上重型的Vue全家桶加独立前端工程。原因很实际毕设答辩看的是完整性和流畅度。用Thymeleaf把所有页面模板和后端放在同一个工程里部署时一个jar包搞定演示时不容易出幺蛾子。如果选了前后端分离你需要维护两个工程、处理跨域、打包部署时还要注意静态资源路径问题——多出来的工作量不会提高你的答辩分数。当然如果你是前端基础很好、希望作品集里多一个前后端分离项目那就用Vue Element UI做管理后台界面这部分在社区的实践场景中就是典型的内部管理平台形态前后端分离也是真实行业的普遍架构。这里我的建议是看你给自己设定的期望值保守方案选Thymeleaf加分方案选Vue分离但前提是你有把握在预期时间内写完。3.4 微服务与中间件不要为了技术而技术有些同学看到“社区”“康养”这类词就想着上微服务、上Redis缓存、上消息队列。我劝你冷静一下。毕设项目的评分核心是“问题解决得是否完整、技术选型是否合理”不是“用了多少新技术”。一个单体SpringBoot应用 MySQL 定时任务完全能承载演示规模的数据量而且逻辑更清晰、更容易调试、部署更简单。如果你的论文章节需要体现“扩展性思考”可以单开一个小节谈谈未来如何拆分提醒服务、引入MQ削峰、用Redis做分布式锁保证任务幂等——作为系统展望来写而不是真的在毕设阶段硬上。这是性价比最高的做法。3.5 部署与演示环境本地开发环境推荐JDK 1.8或11Maven 3.6MySQL 5.7或8.0IDEA旗舰版。数据库可视化工具用Navicat或DataGrip都行。部署演示时一台普通笔记本足矣——SpringBoot应用内存占用很小演示起来毫无压力。如果想让答辩演示更“稳”有个实操小技巧提前把MySQL服务设为开机自启项目打成jar包后用java -jar命令启动所有服务启动时间控制在30秒内。评委说“请演示一下”的时候你打开浏览器直接访问local地址页面秒开印象分会好很多。4. 核心数据模型设计把“个性化提醒”落到数据库表上数据模型是这套系统的地基。我见过不少同学兴致勃勃写了很多接口结果数据库字段设计不合理后端代码越写越拧巴。这里我把核心表结构的设计思路完整拆开讲直接照着建表就能用。4.1 用户与权限相关表用户表sys_user不必多说字段包括id、用户名、密码BCrypt加密存储、真实姓名、手机号、角色类型、所属社区、状态等。这里有一个容易被忽略的细节老人和家属应该通过“绑定关系”关联而不是简单地在老人表里加一个“家属姓名”字段。建议单独建一张family_bind表老人ID、家属ID、关系、是否紧急联系人这样未来做“家属端查看老人用药情况”时查询效率高、语义也清晰。4.2 药品字典表药品字典表medicine_info的核心字段id、药品名称、通用名、规格、剂型片剂/胶囊/口服液、用法口服/外用、注意事项、生产厂家。这里我提醒一点药品名称和规格为什么要分开——因为同一个药品不同厂家生产的规格可能不同比如阿莫西林胶囊有0.25g和0.5g两种规格用药计划的剂量必须以具体规格为准。合并成一个字段后面的剂量计算和记录展示都会混乱。4.3 用药计划表全系统核心提醒规则不能简单地设计成“每天8点”因为真实场景里有大量“隔天一次”“每周两次”“随早餐服用”这类个性化规则。我的推荐方案是把规则拆成两块字段计划基础字段老人ID、药品ID、单次剂量、剂量单位、总疗程可选、开始日期、结束日期、状态启用/停用。提醒规则字段提醒方式每天/隔天/自定义周期、间隔天数隔天为2、每周一次为7、自定义星期如周一、周四、提醒时间可以配置多个时间点、提前量提前几分钟提醒、二次提醒延迟分钟数、是否启用语音播报等。这里有个常见的设计陷阱如果只需要表达“每天早上8点”一个remind_time字段就够了但当需求变成“每隔8小时”“每天两次分别在早饭后和晚饭后”单字段方案就崩了。所以建议引入“提醒策略子表”或“时间规则JSON字段”。考虑到毕设的展示清晰度我更推荐把规则显式做几个字段让数据库结构在任何工具里都能直观展示而不是塞一个黑盒JSON答辩时讲解更顺畅。用SQL示意核心表结构CREATE TABLE med_remind_plan ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL COMMENT 老人用户ID, medicine_id BIGINT NOT NULL COMMENT 药品ID, dose_value DECIMAL(8,2) NOT NULL COMMENT 单次剂量数值, dose_unit VARCHAR(20) NOT NULL COMMENT 剂量单位片/粒/ml, plan_start_date DATE NOT NULL COMMENT 计划开始日期, plan_end_date DATE NULL COMMENT 计划结束日期空表示长期, rule_type TINYINT NOT NULL COMMENT 1-每天 2-隔天 3-按周 4-自定义周期, interval_days INT NULL COMMENT 规则类型2时间隔天数, week_mask VARCHAR(20) NULL COMMENT 规则类型3时周一~周日掩码如1,4表示周一和周四, remind_time VARCHAR(20) NOT NULL COMMENT 提醒时间格式HH:mm,可多个用逗号分隔, advance_minutes INT DEFAULT 0 COMMENT 提前提醒分钟数, retry_minutes INT DEFAULT 30 COMMENT 未确认后的二次提醒延迟分钟数, voice_enabled TINYINT DEFAULT 1 COMMENT 是否启用语音播报, status TINYINT DEFAULT 1 COMMENT 1启用 0停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );这个表设计好之后后面写“个性化提醒”的业务逻辑就会非常顺畅——解析规则类型生成下一次提醒时间点完全可控可查。4.4 提醒记录与服药反馈表提醒记录表remind_log记录每次提醒的生成时间、计划ID、老人ID、提醒渠道、送达状态、确认状态。确认状态是这条链路的“状态机”建议用枚举定义待提醒、已发送、已确认、超时未确认、已升级通知家属。用状态机来管理提醒生命周期比一堆分散的状态字段严谨得多。服药反馈表medication_record记录老人最终的实际服药行为包括确认时间、确认方式手动点击/语音应答、反馈备注如“服药后轻微不适”。这张表也是后续统计“按时服药率”的数据来源。4.5 报表统计怎么取数统计报表的SQL逻辑不复杂核心指标有两个口径按时服药率 当月按时确认次数 ÷ 当月应服药计划次数漏服次数 当月超时未确认且未补确认的记录数有一个开发时的坑要提前规避提醒记录的“应服药计划次数”不能直接等于用药计划的次数乘以天数而要结合计划的起止日期、状态判断。如果计划中途被停用停用日期之后的记录不应计入分母。这类口径问题建议在文档里写清楚论文的“数据统计模块设计”一章也能多写两页。5. 提醒触发引擎这是“智能”二字的灵魂这个系统的技术核心不在增删改查而在提醒触发引擎。它解决的核心问题是系统如何知道此时此刻该给谁发提醒。我分两层来讲基础实现和进阶策略。5.1 方案一Spring自带定时任务推荐起步方案SpringBoot提供了Scheduled注解配合EnableScheduling开启用cron表达式指定执行周期就可以实现“每分钟扫描一次到期提醒”的逻辑。cron表达式形如0 0/1 * * * ?代表每秒0秒、每一分钟触发一次。每次任务触发后要做的核心事情从数据库查出所有“启用状态”的用药计划逐一解析计划的时间规则判断“当前时间是否已经到达某个提醒时间点”且“今天是否在该计划的有效日期范围内”判断“该计划在当前时间段是否已经生成过提醒记录”——防止重复提醒生成提醒记录并通过短信/站内消息/语音等渠道触达用户。逻辑本身不复杂但要注意几个实现细节。第一状态判断必须用数据库记录做幂等——如果服务重启过内存状态全丢了必须以提醒记录表里“是否存在某计划某时间点已生成的记录”为准不能只靠内存变量。第二时间比较建议统一使用服务器本地时间并把“时间点”转换为“分钟序号”避免Date比较时秒级别误差造成漏提醒。第三查询计划列表时务必加状态过滤和分页如果老人数量多了每次全表扫描所有计划再逐条判断性能会肉眼可见地变差。示意核心代码逻辑Component public class RemindScanTask { Scheduled(cron 0 0/1 * * * ?) public void scanAndTrigger() { ListRemindPlan activePlans remindPlanMapper.selectActivePlans(); String currentMinute LocalTime.now().format(DateTimeFormatter.ofPattern(HH:mm)); for (RemindPlan plan : activePlans) { // 1. 判断当前日期是否在计划有效区间内 if (!isDateInRange(plan)) continue; // 2. 判断当前分钟是否匹配提醒规则 if (!isRemindMinute(plan, currentMinute)) continue; // 3. 幂等校验该计划在当前时间点是否已经触发过 if (remindLogMapper.existsByPlanAndTime(plan.getId(), LocalDate.now(), currentMinute)) continue; // 4. 生成提醒记录 触达老人/家属 doRemind(plan, currentMinute); } } }5.2 方案二Quartz定时任务进阶加分项如果想让技术含量再上一个台阶可以将定时任务模块换成Quartz。Quartz支持任务持久化、动态创建任务、失败重试在真实项目中用得很多。答辩时你可以主动提出“基础版我用的Spring Schedule进阶版我调研了Quartz它的好处是可以对每个老人的提醒计划动态创建独立Job配置修改后不需要等每分钟扫描。”——这句话一出来评委对系统深度的印象分会明显提升。但我还是建议你先把方案一跑通再考虑是否升级。因为Quartz的JobStore配置、调度器生命周期管理、内存任务与数据库任务的同步都需要额外精力而方案一已经能稳定完成毕设需求。5.3 个性化提醒策略从“统一提醒”到“千人千面”“个性化智能提醒”的这个前缀核心体现在几个设计点上时间个性化不同老人的作息习惯不同有的习惯早起有的需要午休后提醒。用药计划表里每个计划都有独立的提醒时间天然支持“千人千面”。内容个性化提醒文案不应是统一的“请按时服药”而应包含老人姓名、药品名称、剂量、特殊注意事项如“饭后服用”“服药后多喝水”。这些字段在药品字典表和计划表里都有拼接文案时取用即可。方式个性化不同老人对提醒渠道的接收习惯不同。有的老人用不惯智能手机需要家属或护工端语音播报或电话提醒有的老人习惯看微信。系统可配置“首选提醒渠道”和“备用提醒渠道”主渠道超时无响应后自动切换备用渠道这就是前面提到的升级式提醒。频次个性化首次提醒后若老人在设定时间内未确认系统自动触发二次提醒仍未响应则通知紧急联系人。每个计划都可以独立配置“二次提醒延迟分钟数”和“是否通知家属”体现系统的柔性设计。这一整块内容写进论文里既可以呼应“智能”二字又有具体的代码实现支撑不是空喊口号。5.4 消息触达方案的落地选择消息触达是提醒引擎的最后一公里。毕设阶段我不想推荐需要企业资质才能接入的短信服务如阿里云短信需要签名审核和资质申请个人开发者很难通过。我更推荐以下三种务实的方案站内消息必做系统内置消息中心每次提醒都向老人的账号推送一条站内消息。老人登录系统或家属登录查看时能看到未读的用药提醒。“站内信未读红点”是最保底也最可控的触达方式。邮件或微信通知选做如果有测试用的邮箱可以用JavaMail发送提醒邮件到家属邮箱如果有微信公众号测试号也可以用模板消息接口推送。这类方案不需要企业资质适合演示。模拟短信接口演示兜底在application.yml里配置一个mock短信开关开启后短信发送动作会打印到日志文件同时往短信记录表里插入发送成功记录。答辩演示时你打开日志文件能看到一条条真实的“发送短信”记录——效果上等同于短信功能技术上你自己也清楚这是可替换为真实短信服务的。这里有一个很重要的答辩话术“本项目已将短信发送抽象为MessageSender接口当前实现为模拟方案未来只需替换为阿里云短信或腾讯云短信的SDK实现即可扩展性已经预留。”讲清楚这个设计比自己偷偷接一个不可能过审的短信服务强太多。6. 开发调试中的高频踩坑记录含定制服务经验这个项目我前后帮同学调试过不止一版下面这些坑是出现频率最高的提前写出来帮你省时间。6.1 时间错乱测试环境没到点就疯狂提醒很多同学的定时任务在本地跑起来后发现提醒疯狂触发或者干脆不触发排查半天发现是时区问题。默认情况下JDK的LocalDate.now()和LocalTime.now()依赖的是运行环境时区的系统时间如果MySQL连接的serverTimezone参数配置不当比如使用了UTC数据库存储的时间和Java本地时间会差8个小时。当你在代码里混用Java时间、SQL时间函数和数据库字段类型时就会出现“明明数据库里是早上8点Java判断当前时间已经是下午4点”之类的诡异问题。解决建议连接串统一加serverTimezoneAsia/Shanghai数据库时间字段统一用DATETIME类型并让应用层写入时间不要在SQL里依赖NOW()函数那用的是数据库服务器时区。测试提醒逻辑时可以用一个独立的“模拟时间”配置来缩短周期比如把调度cron改成每5秒一次把提醒时间临时设为当前时间后1分钟验证逻辑正确后再调回正式参数。6.2 重复提醒重启服务后老人在同一天收到两条重复消息这个坑的根本原因是“幂等”没做好。如果提醒生成逻辑里对“某计划在某个提醒时间点是否已生成过提醒记录”没有做数据库查询校验那么每次服务重启后扫描任务重新执行时由于内存或静态变量被清空系统会“忘记”之前已经生成过提醒从而再次触发。更隐蔽的情况是多个实例同时跑虽然毕设一般单实例或cron触发时任务执行时间过长上一次任务还没跑完下一次又开始了。应对方案分三层第一在提醒记录表上建唯一索引plan_id, remind_date, remind_time数据库层面保证同一天同一个时间点只允许一条记录第二生成提醒前先查询该组合是否存在第三定时任务方法加分布式锁单实例时可用ReentrantLock或Just同步关键字兜底防止并发执行。这三层叠加基本可以封死重复问题。6.3 前端页面在手机端显示错乱虽然管理端主要在电脑上用但老人端或家属端往往也会在手机上打开。如果直接用Thymeleaf写桌面端布局到了手机上表格溢出、按钮太大或太小都是常态。解决思路有两个一是用Bootstrap栅格系统做响应式布局给卡片和按钮设定合适的断点二是单独为老人端做一套极简大按钮页面——字体大、颜色醒目、按钮面积大一个页面只做一到两个操作确认吃药、查看说明。考虑到这个项目的场景我甚至建议你把“适老化”当做一个专门的亮点来写大字体、高对比度、语音播报入口在论文里可以单独成为一章“基于适老化设计的交互优化”答辩时非常加分。6.4 数据库字段类型选择剂量、状态这类字段别用错DECIMAL类型的金额、剂量计算时尽量在代码中用BigDecimal而不是Double或Float避免精度丢失。提醒状态字段不要用boolean因为状态不止两种建议用tinyint 常量类/枚举类定义语义。时间区间查询比如统计某天的服药记录要小心between和 小于的边界问题最稳妥的写法是使用 2025-01-01 00:00:00 AND 2025-01-02 00:00:00。6.5 定时任务在Windows本机调试的坑很多同学用Windows做开发机Spring的定时任务默认是串行执行的如果你的任务里包含网络请求比如发送站内消息后又更新数据库任务周期设置太短、任务执行时间过长就会出现任务堆积。调试时建议把cron周期放宽比如每30秒或每1分钟同时在任务方法里加System.currentTimeMillis()日志确认每次执行的启动与结束时间能非常直观地判断是否有重叠。7. 源码交付、文档组织与答辩准备的实战建议7.1 源码拿到手之后先别急着跑先过这三关如果你拿到的是一套别人做好的源码我的建议是不要上来就启动先把交付内容“读薄”看README和数据库初始化脚本有没有建库SQL、样例数据、默认账号密码。没有README的项目先补一份——这既是给自己留底也是评阅老师会看的内容。理清启动依赖顺序先启动MySQL导入SQL确认Redis如果项目用了已启动检查application.yml里的数据库连接参数是否和本机环境一致最后再启动SpringBoot主类。很多“启动报错”的问题80%出在环境参数不一致而不是代码本身有bug。用演示数据走一遍主流程登录管理员账号建一个老人档案配一条用药计划把提醒时间设成当前时间之后2分钟等着看提醒是否正常触发、确认后反馈是否记录、家属端是否收到通知。这一条链路走通了你的项目就真正“能用”了。7.2 文档撰写的重点章节铺排毕设论文一般包含摘要、绪论背景、意义、国内外现状、需求分析、系统设计、系统实现、系统测试、总结与展望。针对这个题目我建议你在几个章节上重点发力国内外现状这块素材很多——美国有MedMinder药盒、日本有服药机器人、国内有各类智慧养老平台写的时候注意引用具体产品和可查证的公开信息不要只说“随着科技的发展”这种空话。需求分析把2.1节列的角色和功能边界展开成用例图规范描述注意区分“功能性需求”和“非功能性需求”后者至少涵盖性能并发量、安全性密码加密、权限控制、可靠性提醒任务的重试与幂等。系统设计架构图、功能模块图、数据库ER图、核心表结构说明再加一张“提醒触发序列图”——这是技术深度展示的重点。系统测试除了常规的功能测试用例表建议加一块“提醒场景专项测试”包括准时提醒测试、二次提醒测试、漏服通知测试、重复提醒防护测试用表格记录输入、预期输出、实际结果、是否通过。这块内容最能体现你“真正跑过”了这个项目。7.3 答辩演示脚本把最打动人的三分钟练熟我给你一个亲测好用的演示脚本思路总时长控制在5分钟左右开场30秒一句话说清楚项目背景和核心价值——“这是一个面向社区老年康养场景的服药提醒系统核心解决老年人漏服、错服药物的现实痛点技术上采用SpringBoot构建后端服务实现了个性化提醒引擎和完整的服药反馈闭环。”功能演示2分钟演示老人档案创建 → 用药计划配置设置个性化提醒时间和二次提醒规则 → 管理员视角看到系统当前待触发的提醒列表 → 模拟提醒触发展示站内消息和日志中的发送动作。闭环演示1分钟模拟老人点击“确认已服药”展示服药记录生成模拟老人不点击等待升二级提醒展示家属/护工通知记录生成。亮点总结1分钟强调个性化提醒规则引擎支持每天/隔天/按周/自定义周期、幂等的提醒机制、适老化界面设计以及预留的消息接口扩展性。这套演示顺序的逻辑是“先讲场景、再讲操作、再讲数据、最后讲技术”评委跟着你的节奏走思路非常清晰提问也容易落在你准备好的点上。7.4 定制服务中我常帮同学改的三种需求这几年接触案例中同学拿到源码后最常见的定制需求是以下三类你也可以提前想想自己是否需要多端适配改造把原本只面向管理端的系统补一个移动端H5页面并优化适老化交互。提醒规则扩展增加“按农历日期提醒”或“按医嘱疗程自动到期提醒”等个性化场景。统计图表增强在原有报表基础上叠加周趋势对比、社区整体服药率排行榜等图表让数据模块更丰满。改造的原则是先画好改动影响面再动手——比如改提醒规则就会影响计划表结构、扫描逻辑、前端表单、测试用例四块别只改了一个地方就以为完事了。写在最后的一点个人体会帮人调试这个项目的过程中我最深的感受是答辩时能拿到高分的往往不是源码写得最炫的而是能讲清楚“我为什么这么设计”的。一个社区老年康养服药提醒系统听起来不难但把“提醒”这两个字做深要处理时间规则解析、幂等并发、多渠道触达、状态流转、反馈统计每一个环节都有值得深挖的技术细节。如果你正在做这个课题我的建议是抓住两条主线一条是业务闭环“计划→提醒→反馈→统计”另一条是技术干线“SpringBoot 定时任务 个性化规则引擎”。把这两条线吃透不管是自己写还是拿源码二次开发你都能做到心中有数。最后再叮嘱一句答辩前一定把“模拟短信接口日志展示”这个演示动作练熟练——它是全场最直观说明“系统确实在跑”的证据。