企业官网建设流程全解析

毕设选题季，Java方向的老哥老姐们应该都刷到过这个题目——“基于Springboot个性化智能提醒的社区老年康养管理系统”，挂在前排的往往还带一句“智能药物提醒和管理”，配套完整前后端、说明文档、LW（论文）甚至调试定制服务。我当年做这个方向的时候，市面上还没有这么多现成模板，完全是自己从零抠出来的，所以看到这类标题挺有感触。

先说说这个题目本身值不值得选。社区老年康养管理系统，本质上是“社区管理 + 健康档案 + 康养服务”的垂直领域管理系统，技术栈用的又是Java系最稳的SpringBoot。但它和普通的学生管理系统、课程管理系统最大的区别在于：药物提醒背后有一条完整的时序逻辑链路，这块做好了，项目的技术含量会明显上一个台阶，答辩的时候也有东西可讲。如果只是把老人信息做做增删改查、药物表单存个数据库，那这个项目就浪费了一半的价值。

这篇文章我不打算给你抄代码，网上卖源码的一抓一大把，我重点讲清楚这个系统该怎么策划、数据库怎么设计、药物提醒调度怎么实现不翻车、以及部署和文档答辩阶段最容易被追问的细节。按我的经验，把这篇看明白再动手，比你直接买一份vue3后台管理系统+SpringBoot代码硬啃要有效得多。

1. 选这个题目前，先把系统边界和核心需求想清楚

社区老年康养管理系统，说白了是给社区服务中心用的。它管的不只是老人，还要管家属、管护工、管用药计划、管健康打卡记录。我见过很多同学拿到这种题目，上来就把管理端菜单开成一排——用户管理、角色管理、日志管理、老人管理、药物管理、订单管理，最后做出来一个“大杂烩后台”，看起来什么都有，答辩时老师一问“你这个系统解决的核心问题是什么”，就答不上来。

1.1 核心场景拆解：谁在用、什么时候用、用到什么程度

我当初画用例图画到一半，发现自己陷入了一个误区：想把所有角色的所有操作都做出来。后来我停下来，先列了三组问题：

• 老人自己用得动手机吗？多数高龄老人不是直接操作系统的，真正高频操作者是护工和家属。
• 药物提醒提醒谁？如果只是后台弹一条记录，提醒没有意义。提醒的触达对象应该是护工和家属，而不是“系统管理员”。
• 提醒之后要闭环吗？吃了没吃、谁确认的、漏服了有没有人跟进，这些必须形成记录，否则就是“只提醒不管理”。

把这三组问题想明白后，系统边界就清楚了：后端管理端面向社区工作人员，负责老人档案、护工排班、药物库维护；老人端或者家属端面向轻度交互场景，主要是接收提醒、确认服药、查看健康报告。

考虑到学生的精力有限，这里给一个稳妥的分端方案：

• 管理端：Vue3 + Element Plus，跑在浏览器上，做全部数据管理。
• 家属/老人端：不一定要单独开发App，可以选择H5移动端或者微信小程序，只做提醒确认、漏服上报、健康打卡三件事。
• 后端：SpringBoot 2.x + MyBatis-Plus + MySQL，认证用JWT，权限用Spring Security。

1.2 功能模块不要贪多，按“服务闭环”来划分

普通管理系统的模块划分是按“实体”来的，我建议你按“服务链路”来划分，这样文档好写，代码结构也清晰。我当时最终确定的模块是这样：

看到没有，药物提醒在这里不是一个孤立的“小功能”，它横跨了用药计划、智能提醒、消息通知三张核心表。它才是整个项目的“题眼”。

2. 数据库设计：一张主计划表加一张流水表的经典套路

数据库设计这块我吃过亏。最初做药物提醒，我只建了一张“用药提醒表”，字段有老人ID、药品名、提醒时间、备注。结果做到一半发现需求变了：老人早晚用药剂量不同，甚至同一个时间点要吃两种药，周末和周中也不一样。一张表根本扛不住。

后来我改成“计划 + 流水”的两层设计，这也是业内药房管理系统通用的做法，你可以直接套用。

2.1 用药计划层：抽象出可重复执行的模板

核心表是medicine_plan，描述的是“一位老人的某个用药方案”，字段大致是这样的：

CREATE TABLE medicine_plan ( id BIGINT PRIMARY KEY COMMENT '主键', elder_id BIGINT NOT NULL COMMENT '老人ID', guardian_id BIGINT COMMENT '默认确认人/家属ID', plan_name VARCHAR(100) COMMENT '方案名称，如“降压药早间方案”', start_date DATE NOT NULL COMMENT '开始日期', end_date DATE COMMENT '结束日期，空表示长期', status TINYINT COMMENT '0草稿 1启用 2暂停 3过期', create_time DATETIME, update_time DATETIME ) COMMENT='用药计划主表';

以及medicine_plan_item，表示“这个计划里具体什么时间吃什么药、吃多少”：

CREATE TABLE medicine_plan_item ( id BIGINT PRIMARY KEY, plan_id BIGINT NOT NULL, medicine_id BIGINT NOT NULL COMMENT '药品ID', dosage VARCHAR(50) COMMENT '单次剂量，如“1片/5mg”', remind_time VARCHAR(20) NOT NULL COMMENT '提醒时间，如08:00', week_mask TINYINT COMMENT '周重复掩码，1周一 2周二 4周三...', remind_channel VARCHAR(20) COMMENT 'sms/wechat/app', is_meal_related TINYINT COMMENT '是否随餐服用', sort_order INT ) COMMENT='用药计划明细';

这里week_mask是个亮点，用二进制位记录周几需要提醒，比如只在周一、周三、周五提醒，mask就是2 + 8 + 32 = 42。这个设计在存储上很省，查询时用位运算就能过滤，答辩时老师看到这个会眼前一亮。

2.2 提醒流水层：每天为每个计划生成待办事项

计划是“模板”还不够，因为提醒必须落到具体的某一天、某一次。每次执行提醒，系统要先把“今天的计划明细”展开成“今天的具体提醒任务”，记录到remind_task表：

CREATE TABLE remind_task ( id BIGINT PRIMARY KEY, plan_item_id BIGINT NOT NULL, elder_id BIGINT NOT NULL, guardian_id BIGINT COMMENT '本次实际通知对象', remind_time DATETIME NOT NULL COMMENT '本次应提醒时间', expire_time DATETIME COMMENT '过期时间，超过则标记漏服', status TINYINT COMMENT '0待提醒 1已通知 2已确认 3已忽略 4已漏服', confirm_time DATETIME COMMENT '确认时间', confirm_by VARCHAR(50) COMMENT '确认人角色：guardian/nurse/elder', remark VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT='提醒任务流水表';

这条流水表是整个系统的发动机。定时任务每天凌晨把未来几天内的计划明细批量展开成提醒任务，类似于“排课表”的思路。真正提醒的动作，是扫描status = 0且remind_time到了的任务，再发送通知。这样做的好处有三个：

• 提醒时间可追溯，不会因为程序重启丢掉任务。
• 状态可扩展，随时能加“已忽略”“已过期”等状态。
• 报表好统计，漏服率、准时率都可以直接基于这张表聚合。

2.3 冗余字段和索引的取舍

提醒任务表是高频读写表，查询条件基本锁定在elder_id + remind_time + status，所以联合索引一定要建好。我踩过一个坑：线上数据量一大，没走索引的全表扫描直接把CPU打满，而MyBatis-Plus的分页在这种场景下特别容易写出慢SQL。后来我把索引设计成：

KEY idx_remind_status_time (status, remind_time), KEY idx_remind_elder_time (elder_id, remind_time)

前者服务定时任务扫描，后者服务端查询。同时要注意，发布提醒之后更新状态的语句要轻量，不要动不动updateById把所有字段都更新一遍，写成：

UPDATE remind_task SET status = #{status}, confirm_time = NOW() WHERE id = #{id} AND status = #{oldStatus}

这里带上status条件，既防止并发重复确认，还自带乐观锁的效果。

3. 药物提醒调度的实现：从“定时任务是个Java类”到“不丢一条提醒”

这是整个项目技术含量最集中的地方，也是你答辩要重点展示的部分。你要让老师相信，你做的不是“一个定时器每天跑一下”，而是一个可靠的提醒调度链路。

3.1 为什么选择Spring自带的@Scheduled而不是上Quartz或XXL-Job

很多毕设课程里会教你集成Quartz，甚至劝你上分布式任务调度平台。我的看法是：毕设阶段切忌过度设计。康养管理系统跑在社区服务中心，一天提醒量可能就几千条，单机完全够用。Spring自带的@Scheduled配合数据库状态机，反而更透明、更好调试。

如果你在论文里写了“使用XXL-Job分布式调度”，答辩老师大概率会追问：调度中心挂了怎么办？任务分片策略怎么定的？路由策略选的什么？你这套系统真需要分布式吗？这些问题很难讲圆。反而是@Scheduled+ 数据库锁，你能把每一行逻辑都讲清楚。

3.2 调度核心代码怎么写才不容易翻车

我的定点扫描逻辑大概长这样：

@Component @Slf4j public class RemindScanScheduler { @Autowired private RemindTaskMapper remindTaskMapper; @Scheduled(fixedDelay = 30000, initialDelay = 10000) public void scanAndSend() { // 滑动时间窗：提前2分钟开始发，避免刚好卡在秒级边界 Date start = DateUtil.offsetMinute(new Date(), -2); Date end = DateUtil.offsetMinute(new Date(), 2); List<RemindTask> taskList = remindTaskMapper.selectList( new LambdaQueryWrapper<RemindTask>() .eq(RemindTask::getStatus, 0) .between(RemindTask::getRemindTime, start, end) .last("LIMIT 200")); for (RemindTask task : taskList) { try { sendRemind(task); } catch (Exception e) { log.error("remind send failed, taskId={}", task.getId(), e); // 不重试？看下面说明 } } } }

这里有几个细节要展开说。

为什么用fixedDelay而不是cron？定点任务怕的是上一次没跑完、下一次又开跑，导致重复扫描。fixedDelay强制等上一次任务跑完再隔30秒扫描下一轮，天然规避并发执行。如果你用cron，还必须额外加分布式锁或synchronized，没必要。

时间窗为什么要设成前后2分钟？因为定时任务被Spring调度时并不是精确到秒的，尤其是任务多的时候，延迟几秒很常见。如果只扫描“当前分钟整”的数据，很容易漏掉边界上的记录。用前后2分钟的滑动窗口，同时把状态置成“处理中”来防止重复发送，是工程上常见的折中办法。

任务一条失败，不要一条重试到底。邮件也好、短信也好，第三方接口偶尔会抖动。如果发失败当场无限重试，会把线程卡死。正确做法是同一个任务最多重试2到3次，并且重试间隔递增；超过重试次数标记status = 5（发送失败），等待人工介入。这个策略可以参考：

if (task.getRetryCount() >= 3) { remindTaskMapper.markFailed(task.getId()); return; } // 否则更新 retryCount = retryCount + 1，延迟到下一轮扫描再试

3.3 提醒闭环：确认、漏服、补录三兄弟不能少

提醒发出去不算完，必须有人确认“药已经吃了”。这里我设计了三种终端动作：

• 护工端确认：护工看着老人把药吃下去，在管理端或移动端点“确认”，remind_task.status变成2。
• 家属远程确认：家属看到微信提醒后，回复“已服药”，其实本质上也是调同一个确认接口。
• 超时自动漏服：如果过了expire_time还没人确认，定时任务把status从0批量更新为4，并且生成一条漏服记录，推送给家属和值班护工。

这个“Eat or Not”闭环，就是整个系统相对普通增删改查系统的差异化亮点。你在写论文的时候，建议把这部分的时序图讲透，从“计划生成”到“任务展开”，再到“通知触达”和“状态收敛”，一步步画清楚。

4. 前置准备与开发环境：选对版本组合，能少掉一半头发

SpringBoot项目让人崩溃的往往不是业务代码，而是环境问题。尤其在我带的毕设小组里，见过太多因为版本不匹配、依赖冲突导致项目起不来的情况。以下是我实测比较稳的一套组合。

如果是下载的源码，启动前务必检查三个地方：application.yml里的数据库账号密码、pom.xml里的依赖版本、前端.env里的接口地址。我见过太多人卡在“明明是正确代码却连不上数据库”，最后发现是MySQL时区配置或者密码加密规则不对。

4.1 Maven私有依赖和打包的坑

毕设项目里经常用到一些从Gitee/GitHub下载的通用模块，如果作者没有上传到中央仓库，你本地Maven仓库里缺了这些依赖，编译直接失败。处理方式有三种：

• 把依赖jar包放到项目lib目录，通过systemPath引入；
• 在本地用mvn install:install-file把jar装进本地仓库；
• 换成公开可用的版本。

我个人更推荐第三种，因为毕设代码里用的私有工具类，百分之八十都可以用官方依赖替代，没必要硬啃别人的封装。

另外，打包时要注意SpringBoot的repackage配置。默认spring-boot-maven-plugin会把项目打成一个可执行的fat jar，但如果你同时需要依赖其他模块，扫描范围要确认清楚。前端Vue项目打包后生成的dist目录如果拷贝到SpringBoot的static目录，需要关掉后端的静态资源缓存，否则改了前端文件不刷新，很容易误以为代码没生效。

5. 前后端联调与移动端通知：这条链路最考验耐心

5.1 管理端页面的“关键操作链”怎么排

管理端建议按这样的菜单层级来组织：

• 长者档案：列表、新增、详情、家属绑定。
• 药物管理：药品库、用药计划、提醒记录、漏服列表。
• 健康监测：打卡记录、异常列表。
• 康养服务：活动发布、报名审核。
• 系统管理：用户、角色、日志。

其中“用药计划”页面是核心中的核心，它需要支持按老人查看计划、为某个计划添加多个药品明细、设定每周循环的提醒时间。这个页面的表单校验也最繁琐，我建议把时间选择器和“周几重复”的多选组件做成独立子组件，否则编辑器里代码会堆成一座山。

5.2 移动端通知的落地：短信、微信、App消息怎么选

毕设阶段别接太多第三方服务，能用模拟的尽量模拟。但完全模拟又显得假，老师可能会问“你提醒怎么发出去的”。我的建议是分层处理：

• 站内信：在系统内通知中心保存，前端轮询或者WebSocket推送。这个必须自己实现。
• 微信订阅消息：小程序端可以做，但需要认证的小程序账号和模板ID，学生不一定有，可以先做成“记录通知流水+模拟发送”。
• 短信：需要短信服务商接入，毕设不建议真实申请调用，但在通知流水表里设计sms通道即可。

我当时是把“通知发送”抽成了一个NotifyService接口，里面有不同的实现类，类似策略模式。模拟实现打日志，真实实现留好接口，答辩时说清楚“短信通道只需替换实现类即可上线”，这个回答既诚实又专业。

5.3 一个特别实用的技巧：演示环境准备一条“演示链路”

到验收的时候，最尴尬的是现场演示找不到一条能完整走通的老人病历。千万提前准备几条完整的演示数据：模拟一个老人，绑定两个家属，开了两个用药计划，然后往remind_task表里插入几条不同状态的提醒记录，确保“待提醒、已确认、漏服、发送失败”四个状态在界面上都有展示。这样哪怕现场时间到点不对，你也能指着漏服记录说：“这是昨天因家属未确认自动标记的漏服记录，系统已推送通知。”

6. 部署、运行与常见故障排查：让系统在演示时“稳如老狗”

毕设演示最怕的不是功能缺，而是关键时刻崩。我整理几个真实高频故障及我踩坑后的解决方案，按重要程度排序。

6.1 时区问题导致提醒时间偏移8小时

这是最隐蔽也最坑的问题。MySQL连接串里的serverTimezone没配，或者服务器时区不是Asia/Shanghai，会导致数据库时间比本地时间慢8小时，提醒计划全部错乱。排查方法很简单：

# Linux上查看当前时区 timedatectl

解决方式是在application.yml里强制指定：

spring: datasource: url: jdbc:mysql://localhost:3306/kangyang?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

同时，在Java代码里不要用new Date()去拼日期参数，尽量用LocalDateTime.now()配合ZoneId.of("Asia/Shanghai")，避免服务器默认时区搅局。

6.2 跨域和端口占用问题

Vue前端默认跑在5173或8080，SpringBoot跑在8081，前后端联调必然遇到跨域。最省事的方案是让前端请求走代理，在vue.config.js里配置：

devServer: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true, pathRewrite: { '^/api': '' } } } }

但要注意，生产环境下如果你把Vue打包后的dist直接交给后端托管，接口路径就不要再带/api前缀了，否则后端路由匹配不上。我见过太多人前后端分离在开发时没问题，一到部署就404，多半是这个前缀问题。

6.3 定时任务为什么没跑起来

@Scheduled不生效，最常见的原因有三个：

• 启动类没有加@EnableScheduling；
• 定时任务方法所在的类没有被Spring扫描到；
• 多个SpringBoot应用实例只连同一个数据库，导致同一个任务被重复执行。

前两个都是小问题，第三个值得展开。虽然毕设一般不会部署多实例，但如果你把系统打包后同时开了两个端口验证，就会出现同一条提醒发两次的情况。不给系统加分布式锁的前提下，最简单的做法是给扫描SQL加LIMIT 200，同时提醒任务在发送前用UPDATE ... WHERE status = 0做抢占，谁抢到谁处理。

6.4 Docker部署时的内存限制

如果你用Docker来装MySQL或Redis，默认容器没有设置内存上限，在2G内存的云服务器上很容易OOM。建议在容器启动命令里加上：

docker run -d --name mysql-kangyang -m 512m -p 3306:3306 ...

如果是本地开发，那就无所谓了。但我还是建议毕设答辩前，至少在虚拟机或者云服务器上完整部署一遍，因为你永远不知道老师会不会现场让你打开Linux终端看日志。

7. LW（说明文档/论文）撰写的结构与答辩应对策略

说句实在话，很多同学买源码、整代码都整得很顺，最后卡在论文上。这个题目的LW写作有它自己的叙事逻辑，我按我当年答辩顺利通过的经验，拆一下写作骨架。

7.1 论文每个章节该写什么

• 选题背景与研究意义：重点写“老龄化社区养老需求上升”和“传统人工提醒的局限性”，不要空喊口号。
• 相关技术介绍：SpringBoot、MyBatis-Plus、Vue3、MySQL，每样写清楚选型原因，加对比表格更好。
• 系统需求分析：把角色、用例、数据流画清楚。这里强烈建议画好“药物提醒时序图”，这是老师爱看的核心图。
• 系统设计：架构图、数据库ER图、接口设计。把第2节里的remind_task表结构讲透。
• 系统实现：按照模块给出核心代码并解释关键逻辑，特别是定时调度和消息推送。
• 系统测试：写功能测试用例表，列清楚每个模块的输入、预期输出、实际输出、结论。再补一段性能测试，比如用JMeter模拟100个用户并发查询提醒记录，观察响应时间。
• 总结与展望：写“未来可以接入智能语音播报”“可以引入家属微信通知”“可以对接社区大屏”这类方向，适度即可。

7.2 答辩时高频追问TOP5及应对

1. “你这个药物提醒是怎么触达用户的？”答：拆成站内信、微信、短信三种通道，通过策略模式实现，模拟通道已跑通，真实通道只需替换实现类。
2. “定时任务如果系统重启了，会不会漏提醒？”答：提醒任务在数据库中有持久化状态，重启后重新扫描未完成任务，不会丢。
3. “如果一条提醒发失败了，怎么办？”答：有重试机制，重试超过3次标记为人工介入，同时通知护工端显示失败清单。
4. “你有什么创新点？”答：多维度的提醒计划配置（周掩码）+ 状态机驱动的闭环管理，将“提醒”和“管理”结合成闭环。
5. “数据库里如果老人同时有10个计划，每天会产生多少条任务？”答：按计划明细展开，每天最多等于所有启用计划明细条数之和，查询和推送性能都可控。

预设这些问题并提前写成答辩稿，你会比临场发挥稳重得多。说到底，毕设答辩老师真正想确认的是“这个系统真的是你做的”“你明白其中的原理”，只要你能把“药物提醒从计划到闭环”这条链路圆滑讲透，分数不会低。

8. 经验建议汇总：如果再让我做一次这个题目

最后按老规矩，给准备上手这个题目的同学几条实在建议，都是我当时用时间换来的。

第一，拒绝上来就写代码。先用三天把用例图和数据表结构定下来，尤其把medicine_plan_item的字段设计好，后面改字段的代价比你想的大得多。数据结构一旦定型，前后端写起来就是流水线作业。

第二，定时提醒不要用Thread.sleep或死循环扫库。老老实实用@Scheduled+ 状态更新，原因前面已经说过。记住，毕设代码追求的首先是可解释性，其次才是性能。花里胡哨的写法反而是老师的突破口。

第三，通知记录一定要落库。不管你有没有真实短信服务，notify_log表必须留着。因为“通知是否发送成功”本身可以被当作系统的一项功能去展示，也可以用来回应老师关于真实性的疑问。

第四，演示前，手动造一批“看起来真实”的数据。老人姓名、家属电话、药物名称都可以编，但状态分布要有层次感。一个成熟的系统演示页面，不是表格全都一样的状态，而是各种状态交错出现，这样才能让老师看到你系统处理不同情况的能力。

第五，本地、服务器各跑一遍。我见过太多人在自己电脑上运行完美，到了答辩现场用学校机房电脑，数据库连不上、端口被占、前端白屏，直接血崩。提前在你自己的云服务器上部署一份，演示就用那台服务器，稳得不行。

这个题目本身不算难，难点在于你有没有把“药物提醒”这条逻辑链路做深、做透、做闭环。技术栈都是Java后端的老朋友，SpringBoot加Vue3的组合在毕设里属于最皮实耐用的搭配，再加上数据库状态机的设计思路，足以让答辩老师觉得你有工程意识。希望这篇拆解能帮你少走我当年走过的弯路，把时间花在真正能提升项目质量的地方。祝各位顺利过审，拿到理想的毕业设计成绩。