SpringBoot+JavaWeb社区老人健康管理系统完整开发详解

做Java项目开发这几年，我调过最多的代码往往不是正式工作里的业务系统，而是毕业季前后被人发过来求帮忙的课程设计和毕设项目。尤其“管理系统”这类选题，几乎每年都会遇到几十份，其中“社区老人健康管理系统”是我认为特别适合拿来当完整范例的一类：业务边界清晰、功能足够展示工作量、还天然带健康档案、随访、预警这些能让答辩老师眼前一亮的模块。这次要拆解的这套基于SpringBoot+JavaWeb的社区老人健康管理系统，我不仅把源码完整跑通，还顺手整理了整套启动、建库、演示和论文配合的流程，正好可以给你做参考。

很多同学拿到一套源码，最开始问的都是“这玩意儿怎么跑起来”，但真正到答辩的时候才发现，跑起来只是及格线。老师更关心的是你懂不懂为什么这样设计、换一个场景你能不能改、某些表为什么要拆开。所以这篇文章我不会只讲“点下一步”，而是把整个项目从需求、表设计、后端实现到部署演示串起来说一遍，适合正处于毕设选题阶段、或者已经拿到源码但还没吃透的读者。

1. 这个系统的“场景底盘”：社区老人健康管理到底要管什么

1.1 一类典型的社区业务单元

先别急着打开IDE，务必先搞清楚系统服务的对象是谁。社区老人健康管理系统，本质上解决的是社区工作人员和基层卫生服务人员对老年群体健康信息的管理问题。过去很多社区都靠纸质档案或者Excel表格记录老人基本信息、体检数据、随访情况，这种方式维护起来有多麻烦，跑过社区业务的同学应该能想象：找一份档案翻半天、整理某个小区高血压老人的名单要手动筛、到了该随访的日子也没人提醒。

这类系统的价值就是把“人、健康档案、体检记录、随访任务”这几样东西串成一个数字化闭环。老人入院登记后形成基础档案，定期体检产生健康指标记录，指标异常时给出预警，工作人员根据预警和周期安排随访，随访结果再写回系统。这套逻辑放在论文里也特别好讲，因为它有清晰的时间线和业务流转关系。

1.2 用户角色和权限基座

做系统设计第一步是划分角色，角色划分会直接决定你后面建表、写拦截器、做页面菜单的工作量。这套系统的角色通常拆成三类，也有项目会做得更细：

• 系统管理员：管用户、管角色、管基础数据字典，通常拥有全部菜单权限。
• 社区健康管理员/工作人员：核心业务使用者，负责老人档案录入、体检数据登记、随访任务处理。
• 老人或家属：以查看为主，可以看自己的健康档案和体检历史，一般不具备编辑权限。

用户角色的权限实现不一定非要上Spring Security这么重的框架，毕设阶段用“用户表带角色字段 + 登录拦截器 + 菜单权限判断”就够了。这样既能在文档里写清楚RBAC（基于角色的访问控制）的思路，又不会因为框架配置问题把自己绕进去。

1.3 核心功能总览

我在跑这套源码的时候把功能做了个整理，做成更直观的功能矩阵：

这个功能矩阵的好处是既能指导你做数据库表，又能直接映射到论文里的“系统功能模块图”和“用例图”，画图的时候不用再临时编功能点。

2. SpringBoot+JavaWeb的组合为什么适合当毕设底座：选型和版本搭配

2.1 SpringBoot到底帮我们省了什么

很多教材还在教Servlet+JSP那套传统JavaWeb写法，但真要在几个月里独立完成一个能演示的管理系统，纯Servlet会把人写崩溃。一个页面查询列表，Servlet那边要处理请求、调用Service、转发、处理乱码，框架层面的重复劳动太多。SpringBoot的价值在于它把Spring MVC的配置自动化了，原来的web.xml、Spring配置文件、MyBatis配置整合等大量样板工作都被自动配置取代，你只要关注Controller、Service、Mapper这三层怎么写。

从学习或答辩的角度看，SpringBoot还有一个隐性优势：它仍然是Java生态里最主流的框架，面试和课程后续接触到的内容不会脱节。你用SpringBoot做一个项目，写简历时可以写“熟悉SpringBoot、SpringMVC、MyBatis”，但如果只写“熟悉Servlet”，竞争力就弱一截。

2.2 版本不合理是启动失败第一元凶

这套系统的技术栈是SpringBoot+JavaWeb，所谓JavaWeb在这里更多指代基于Java语言的Web应用开发方式，不一定非要强绑JSP。实际操作中，我强烈建议你先把版本表格确认清楚再动手：

有些同学手一抖装了SpringBoot 3.x，结果JDK8不支持，被迫换JDK17，再遇到javax到jakarta命名空间迁移，白白浪费两三天。如果目的是快速做完毕业项目，建议直接用SpringBoot 2.7.x。
这不是说SpringBoot 3不好，而是对于查错效率和参考资料的丰富程度来说，2.7.x在中文社区里几乎什么问题都有人踩过、有人回答过。

2.3 前端页面选JSP、Thymeleaf还是前后端分离

关于页面展示这块，我要多讲几句，因为“JavaWeb”这个词在不同人理解里差别很大。如果你的项目打算用JSP，那也算是经典JavaWeb路线，但SpringBoot里用JSP需要额外引入tomcat-embed-jasper依赖，而且JSP打包成jar时会有一些坑，有时候放到服务器上就找不到页面了。相对更省心的方案是用模板引擎Thymeleaf，因为它有SpringBoot官方starter支持，语法和HTML接近，前端页面不需要额外启动Node服务。

当然，现在很多毕设都喜欢做前后端分离，Vue+SpringBoot。前后端分离不是不行，但你要先想清楚：答辩时老师很可能问你跨域怎么处理、打包后怎么部署、如果直接双击运行能不能展示。如果你没有把握把Vue项目构建出的dist目录正确集成进SpringBoot，那我建议演示版本优先用Thymeleaf+Bootstrap或Layui这类服务端渲染方案，等到论文里再写“后续可扩展前后端分离架构”。

3. 数据库设计推演：不要一上来就建表，先想清楚一对多关系

3.1 从需求到核心表清单

我每次给别人审项目，第一件事不是看代码，而是看数据库脚本。表设计烂了，代码写得再花哨也救不回来。这套老人健康管理系统，在落地建表之前应该先列出核心实体：用户、角色、老人档案、体检记录、随访记录、预警记录、公告。实体之间的关系主要是：

• 一个用户可以管理多个老人档案，但毕设里可以直接把“创建人”作为普通字段放在老人档案表中。
• 一个老人有多条体检记录，所以老人档案和体检记录是1对N关系。
• 一个老人可能有多条随访记录，同样也是1对N。
• 体检记录和预警记录可以做成1对0或1对1，也可以独立一张表存预警消息。

核心表大致如下：

这里我用一个小技巧提醒你：表名统一用下划线风格，字段也统一小写加下划线，配合MyBatis-Plus的map-underscore-to-camel-case配置，实体类就能自动映射成驼峰命名。如果一会儿userName一会儿user_name，后面写SQL容易把自己搞晕。

3.2 老人档案表与体检记录表的扩展点

老人生理指标其实并不像想象中那么单一。有的系统只记录血压、血糖，有的还要记录心率、身高体重、血氧、是否吸烟喝酒等。设计时建议把固定字段放在主表里，把容易变化的指标放在体检记录里提高冗余度，但要避免过度设计成一张“指标字典表+指标值表”的复杂结构。

对毕设项目来说，我更推荐适度冗余的宽表设计。比如health_record表保留height、weight、high_pressure、low_pressure、heart_rate、blood_sugar这几个常用字段，每个字段单独一列。查询列表时一行就能展示，做统计图表时也好写SQL。体检记录的基本SQL可以做参考：

sql复制CREATE TABLE `health_record` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `elderly_id` bigint(20) NOT NULL COMMENT '老人档案ID',
  `record_date` date DEFAULT NULL COMMENT '体检日期',
  `height` decimal(5,1) DEFAULT NULL COMMENT '身高cm',
  `weight` decimal(5,1) DEFAULT NULL COMMENT '体重kg',
  `high_pressure` int(11) DEFAULT NULL COMMENT '收缩压mmHg',
  `low_pressure` int(11) DEFAULT NULL COMMENT '舒张压mmHg',
  `heart_rate` int(11) DEFAULT NULL COMMENT '心率次/分',
  `blood_sugar` decimal(4,1) DEFAULT NULL COMMENT '血糖mmol/L',
  `remark` varchar(500) DEFAULT NULL COMMENT '备注',
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意三个容易犯的错误：第一，老人档案和体检记录之间一定要建外键索引，如果elk查询经常用到，至少在elderly_id上加普通索引；第二，Decimal字段要写明精度，比如身高体重保留一位小数；第三，所有时间字段最好都带上默认值，create_time直接用数据库当前时间，省得Java代码里每个插入都要手动set。

3.3 用户权限相关表是否必须做五张表

标准的RBAC设计通常是用户表、角色表、权限表、用户角色关系表、角色权限关系表五张表。但很多毕设管理系统并不需要那么细粒度的按钮权限，把角色表单独拆出来已经算完整。这里有一个很现实的考虑：如果只做“管理员”和“普通用户”两种角色，直接在sys_user表加role_id字段就能实现，创建用户时选择角色即可；如果你想让系统显得更专业，可以再拆sys_role表。但我不建议硬做角色-权限关联，因为一旦做了五张表，代码里的查询逻辑会成倍增加，答辩时被问“你权限表为什么这么设计”反而容易被问住。

4. 核心代码块的实现思路：登录拦截、档案录入、预警触发

4.1 登录拦截器：守住后台安全边界

这类管理系统的后台页面不能允许未登录用户直接访问，实现方式很多，我用SpringBoot的HandlerInterceptor写过一套比较干净的版本。定义一个拦截器类，实现HandlerInterceptor接口，在preHandle方法里获取session中的登录用户，如果为空就直接重定向到登录页：

java复制@Component
public class LoginInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        HttpSession session = request.getSession();
        Object loginUser = session.getAttribute("loginUser");
        if (loginUser == null) {
            // 判断是否为Ajax请求，如果是则返回json，否则重定向到登录页
            response.sendRedirect(request.getContextPath() + "/login");
            return false;
        }
        return true;
    }
}

然后通过WebMvcConfigurer注册拦截规则，注意把登录接口、静态资源路径排除掉：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(loginInterceptor)
                .addPathPatterns("/**")
                .excludePathPatterns("/login", "/doLogin", "/captcha",
                        "/css/**", "/js/**", "/images/**", "/error");
    }
}

用拦截器比在每个Controller里判断session要优雅得多，这也是SpringMVC里比较基础的面试考点。答辩时如果老师问“你怎么控制用户权限”，你就可以明确回答：通过HandlerInterceptor实现登录验证，再结合角色字段进行菜单级别的显示控制。

4.2 老人档案管理的CRUD流程写法

这套系统的核心业务无非是增删改查，但代码结构要清晰。以前见过不少同学把大量SQL写在Controller里，结果一个类上千行，老师看到代码结构直接摇头。推荐结构是Controller接收参数并返回页面或JSON，Service组合业务逻辑，Mapper只负责操作数据库。

老人档案新增功能大致逻辑如下：

java复制@Service
public class ElderlyInfoServiceImpl implements ElderlyInfoService {
    @Autowired
    private ElderlyInfoMapper elderlyInfoMapper;

    @Override
    public boolean addElderly(ElderlyInfo elderlyInfo) {
        if (elderlyInfo == null || !StringUtils.hasText(elderlyInfo.getName())) {
            throw new ServiceException("老人姓名不能为空");
        }
        // 生成档案编号：ELDER + 当前时间戳
        String elderlyNo = "ELDER" + System.currentTimeMillis();
        elderlyInfo.setElderlyNo(elderlyNo);
        elderlyInfo.setCreateTime(new Date());
        elderlyInfo.setStatus(1);
        return elderlyInfoMapper.insert(elderlyInfo) > 0;
    }
}

这里有几个细节值得注意：

• 我加了简单的参数校验，避免空数据入库。
• 档案编号如果不用自增ID，可以用时间戳生成，可读性和查重性都更好。
• 新增之前务必要在页面表单里做必填校验，后端也要校验，两层不能省。

删除数据时，遇到一个常见情况：老人一旦录入了体检记录和随访记录，直接把elderly_info表里的记录物理删除，会导致历史数据变成孤儿数据。我建议使用逻辑删除，在表里加deleted字段，查询时自动过滤。MyBatis-Plus里有@TableLogic注解，配置好之后就不用自己每个SQL都拼条件了，这也算一个可以写进论文的技术细节。

4.3 健康预警和随访提醒的实现方式

健康预警是这套系统最带“智能感”的功能，也是很多同学认为最难的一个点。但实际上毕设阶段不用做机器学习，也不用做什么复杂大数据分析，用简单的规则判断就能实现出很好的效果，还能在论文里用业务规则解释清楚。

我先定义阈值配置，比如收缩压大于等于140或舒张压大于等于90判定为血压偏高，空腹血糖大于7.0判定为血糖偏高。在HealthRecordService里增加一个方法，录入体检记录后调用：

java复制public void saveRecordAndCheckAlert(HealthRecord record) {
    // 1.保存体检记录
    healthRecordMapper.insert(record);
    // 2.查询老人基础档案
    ElderlyInfo elderly = elderlyInfoMapper.selectById(record.getElderlyId());
    // 3.根据指标数据判断是否需要预警
    if (record.getHighPressure() != null && record.getHighPressure() >= 140
            || record.getLowPressure() != null && record.getLowPressure() >= 90) {
        saveAlert(record.getElderlyId(), "血压偏高预警",
                "收缩压" + record.getHighPressure() + "mmHg，舒张压" + record.getLowPressure() + "mmHg");
    }
    if (record.getBloodSugar() != null && record.getBloodSugar() >= 7.0) {
        saveAlert(record.getElderlyId(), "血糖偏高预警", "血糖值" + record.getBloodSugar() + "mmol/L");
    }
}

saveAlert方法做的事就是把预警内容插入health_alert表，同时把status设为0表示未处理。工作人员在首页预警信息列表里能看到“今天新增N条预警”，点击进去可以标记为已处理，再进入随访管理为该老人生成一条随访任务。

随访提醒的日期计算也很简单，常用思路是：工作人员录入随访计划时设置next_follow_date，系统每天对比当前日期，如果next_follow_date在当前日期之后3天内就认为待提醒。这种实现比用定时任务更直观，适合没有部署常驻后台的毕设环境。如果你想写一点技术亮点，可以引入SpringBoot的@Scheduled定时任务，每天凌晨扫描一次随访表，把当天需要随访的老人记录写入消息表，但注意要让主程序有@ComponentScan能够扫描到定时任务类。

5. 项目分层与页面端联动：代码结构决定答辩印象分

5.1 Controller、Service、Mapper三个层次别写混

我一直和做毕设的人说：代码跑不跑得通是一回事，能不能让老师看出来你懂工程规范是另一回事。一个常见的坏习惯是Controller里直接注入Mapper，所有查询在Controller中操作。短期看不出问题，但后续统计、校验、业务规则没地方放，越写越乱。

按照约定分三层：

• Controller：负责接收请求参数、封装页面数据、定向跳转。
• Service：负责处理业务，包括参数校验、组合查询、数据逻辑判断。
• Mapper/DAO：负责与数据库交互，提供单一的数据操作方法。

标准的文件夹结构可以这样组织：

text复制src/main/java/com/example/elder
├── controller        // 登录、老人管理、体检管理等Controller
├── service           // 业务接口和实现
├── mapper            // MyBatis-Plus的Mapper接口
├── entity            // 数据库表对应的实体类
├── config            // 拦截器、Web配置、MyBatis-Plus配置
├── common            // 统一返回结果、异常处理
└── interceptor       // 登录拦截器

实体类与数据库字段的映射关系，我用MyBatis-Plus的注解来对应，比如@TableName("elderly_info")指定表名，@TableId(type = IdType.AUTO)指定主键自增，这样CRUD代码会非常简洁。Mapper接口只需要继承BaseMapper就能获得一批现成的单表操作方法，大大减少SQL编写工作量。手写复杂SQL时，在Mapper.xml中按id和查询条件动态拼接即可。

5.2 数据回显和列表查询中容易踩的坑

在页面端，Thymeleaf和JSP有一个特别容易翻车的点：当你从后台Model放入一个对象列表，页面里如果访问了对象的关联字段，而这个字段没有初始化，框架可能直接抛异常或者显示空值。比如老年列表页上想显示“最近一次体检日期”，如果只查老人档案表，没有联查健康记录表，页面上就无法显示这个字段。

通常解决办法是在Service层做联表查询，用VO类承载页面需要的展示数据，比如ElderlyInfoVO增加latestRecordDate和recordCount字段。查询时先从老人表查列表，再根据所有老人ID批量查询体检记录，在Java里组装好返回。这种“先查主表，再批量查子表”的方式比循环内单查性能高，代码也容易读。

Controller返回页面的方式如下：

java复制@GetMapping("/elderly/list")
public String list(@RequestParam(defaultValue = "1") Integer pageNum,
                   @RequestParam(defaultValue = "10") Integer pageSize,
                   String keyword, Model model) {
    Page<ElderlyInfoVO> page = elderlyService.queryElderlyPage(pageNum, pageSize, keyword);
    model.addAttribute("page", page);
    model.addAttribute("keyword", keyword);
    return "elderly/list";
}

页面里通过Thymeleaf遍历page.records渲染表格，再用page.total渲染分页条。分页插件建议使用MyBatis-Plus内置的PaginationInnerInterceptor，在配置类里注册一下即可，但在参数回传时注意total是long类型，不要把它当int用。

6. 本地部署的完整路径：从JDK配置到首屏展示

6.1 拿到源码后先从这些操作开始

我调试这套源码时，第一步做的就是核对环境，因为太多项目“跑不起来”不是项目问题，是环境问题。无论你从哪个渠道拿到源码，下面这套流程都可以通用：

• 安装JDK1.8并配置JAVA_HOME，在命令行执行java -version能正常输出版本即可。
• 安装Maven，配置本地仓库和阿里云镜像，因为国内直接拉中央仓库依赖比较慢。
• 安装MySQL，把项目中的elder_health.sql导入数据库，注意导入前先检查字符集，避免中文乱码。
• 打开IDEA，用Import Project方式选择项目pom.xml文件，等待依赖下载完成。
• 修改application.yml中数据库账号密码，确保与你本地一致。
• 启动主启动类，观察控制台日志是否出现Tomcat started on port 8080。

每一步看起来简单，但都有对应的坑。比如Maven依赖下载慢，会表现为IDEA卡在解析阶段很久，配好镜像后基本几秒钟就能拉到。

6.2 application.yml里的关键配法

这套项目的配置核心在application.yml，基本配置可参考：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/elder_health?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true
    username: root
    password: 123456
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 10MB

mybatis-plus:
  mapper-locations: classpath*:mapper/**/*.xml
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

url参数里有几个值得关注的：serverTimezone=Asia/Shanghai解决时间差八小时问题；useSSL=false避免MySQL连接时证书警告；allowPublicKeyRetrieval=true解决MySQL8.0下使用caching_sha2_password认证时可能出现的Public Key Retrieval异常。这些配置如果缺失，启动时会报五花八门的错，记住这一套基本能解决90%的连接问题。

6.3 我在这套项目里遇到的启动报错排查

我简单列一个排查清单，读者可以对照排查：

遇到报错不要急着重装环境，先看完整日志。SpringBoot的报错信息通常已经指明位置，比如某个Bean创建失败、某个Mapper扫描不到、数据库SQL写错。这些错误大概率是配置问题，不是你改坏了代码。

7. 论文和答辩怎么跟代码联动：让工作量看得见

7.1 论文目录结构与系统模块的对应

不少同学做项目很快，但写论文时对着空白Word发呆，根本原因是一开始没把代码设计与论文结构对齐。哪怕代码已经写完了，回过去重新梳理也来得及。比较推荐的论文目录大致如下：

• 绪论：介绍老龄化背景和社区健康管理需求，提出系统建设目标。
• 需求分析：对应系统用户角色、功能需求、非功能需求。
• 系统设计：对应总体架构、功能模块划分、数据库表设计。
• 系统实现：对应每个核心模块的代码截图和界面截图。
• 系统测试：写测试用例表，用例要与功能模块对应。

写系统实现时，不要贴大段代码，更重要的是先放页面截图，再用几行核心代码说明实现思路。比如预警功能就贴判断阈值的那几个if条件，比贴整个Service类更高级。

7.2 截图、录制和演示的固定动作

答辩演示最尴尬的情况是现场页面报错或者数据太少。演示前固定过一遍操作顺序：登录，展示首页统计卡片，查询一个老人，进入健康记录列表，录入一条故意让指标超标的记录，刷新预警列表，进入随访页面新增一条记录。这样五分钟内就讲完了从数据产生到业务闭环的整个过程，评阅老师想要看的都覆盖住，万一中途出小差错也不会乱。

录制的演示视频建议在屏幕分辨率1920x1080下进行，先做登录，再按业务顺序操作，最好把系统名和本人姓名在首页签名的位置显示出来。视频时间控制在五到六分钟即可，太长了老师没耐心看。

7.3 答辩中容易被追问的三个问题

一是“你觉得这套系统还有哪些不足”，不要直接说没有。可回答：目前预警规则是固定阈值判断，后续可以通过历史数据分型对每个老人的异常指标做动态个性化判断；再比如数据可视化维度还不够丰富，后续可接入大屏展示。既表明自己知道系统边界，又暗示系统具备扩展性。

二是“为什么要用SpringBoot而不用其他框架”，重点答自动配置和生态成熟，但不要贬低其他技术。

三是“数据库的记录量大了怎么办”，可以回答分页查询已经是标准操作，后续可以引入Redis缓存热点档案数据，在健康记录表上做按月分表。这里不需要你真的实现了，只要逻辑是自洽的，老师就不会揪着不放。

8. 源码交付与定制改造的几句实在话

8.1 拿到源码后先“信任但验证”

标题里有“源码分享”和“一条龙定制”，这确实迎合了很多想快速完成毕设的同学。但作为技术博主，说实话，我建议所有拿到源码的人先做一件事：自己从头把项目启动起来，不要因为对方说“我本地跑过没问题”就直接交。二手源码的坑通常在于数据库脚本不全、找不到配置文件、代码里遗留了他人的绝对路径、把本机目录写死等。你亲手跑一遍，就能提前暴露所有外在因素带来的风险。哪怕最后不修改，也应该清楚每一个按钮的触发链路，这才是源码分享和代码讲解真正有价值的点。

8.2 定制开发最难的是改字段而不是重写页面

“定制”这个词在很多同学脑中等于把系统表头改成自己的题目。实际上最常见的定制需求有两类：一类是换个业务名称，比如把“社区老人健康管理”改成“某社区慢性病管理”或者“教职工体检管理系统”，这时需要改表名的前缀、实体名、页面文字、菜单项；另一类是增加业务字段或表单字段，比如加一个“接种记录”模块，需要改数据库、实体、接口、页面模板四个层面，工作量远比想象中高。

无论你最终是借鉴源码二次开发，还是自己动手改造，都要有一种工程思维：先把表结构梳理清楚，再从页面到Service反向追踪代码，而不是直接在页面上画一个新输入框然后找半天该把值存到哪列。

8.3 代码讲解比源码本身更能决定答辩质量

我在调试这类项目时感触很深的一点是：很多同学对项目没有“手感”，根源就是没听过逐行讲解。源码看得懂和能向别人讲清楚是两码事。代码讲解至少要覆盖三块：项目如何启动和调试、核心表结构设计理由、核心业务代码的执行链路。如果你能把老人生成档案到录入体检再到触发预警这一整条链路讲通，那无论答辩老师怎么换着角度问，你心里都有底。

平时习惯可以先打开Controller，讲一个请求进来之后如何被DispatcherServlet分配、再到Service判断业务、最后通过Mapper操作数据库，再返回输出到页面。以后如果找工作，这套问答思路同样能迁移到SpringMVC相关的面试场景里，一举两得。

最后补一句我个人的体会：做毕设或练手项目，折腾源码的过程有时候比最后提交的产物更值钱。那些深夜对着控制台日志排查，把启动报错逐行看明白的时刻，才是真正从“会用框架”往“理解框架”走的路。这套社区老人健康管理系统只是一个载体，你从里面学到的分层思想、表设计逻辑和排查方法，换个业务场景依然能复用很久。