1. 项目概况与选题价值

每年到了毕设季，总有不少同学在选题表上纠结半天。其实选毕设有个很实在的思路：功能不贪多、技术能讲清、数据好获取、上线能演示，这四个条件一满足，答辩基本就稳了。今天聊的这套“SSM+Java社区老年人健康档案管理”，就是按这个标准去对标的典型选题。

先把这个项目说清楚。它本质是一个面向社区卫生服务中心这类场景的Web信息管理系统，核心任务是把老年人健康档案的纸质台账电子化，实现居民信息维护、健康体检记录、慢病随访登记、数据检索统计这些日常业务。技术栈选用的是Java生态里非常经典的SSM组合——Spring、Spring MVC、MyBatis，前端页面用JSP配合 Bootstrap 来渲染，数据库用 MySQL。整套系统跑在 Tomcat 上，属于标准的企业级分层架构。

这个题选得好不好？我个人的判断是：非常适合本科毕设的体量。它的业务边界清晰，没有复杂的支付、并发、分布式这类容易给自己挖坑的环节；功能模块虽然覆盖面广，但每个功能的实现逻辑都不算深，一个中等水平的同学花八周左右能完整落地。更重要的是，社区老年人健康档案管理本身属于民政与医疗卫生交叉的公共服务领域，多少带一点社会价值，答辩时讲“选题背景”和“现实意义”这一part会非常自然，不太容易出现“老师，我这个系统就是给图书馆/宿舍/班级用的”那种无力感。

再从技术角度看看。SSM这套组合在今天看来虽然不如 Spring Boot 新潮，但学校里很多课程设计、实训项目都还是以它为基础，教材也大量覆盖。用 SSM 做毕设，好处恰恰在于框架本身的复杂度适中，能充分展示你对分层架构、依赖注入、ORM映射这些基本功的掌握。Spring Boot 确实省事，但省事的代价是很多底层细节被封装掉了，答辩时老师追问“MyBatis 的 Mapper 代理是怎么生效的”、“Spring 容器是怎么启动的”这类问题，用 SSM 答起来反而更有话说。

不过这里得说句实在话：这套系统虽然业务不复杂，但想要做得有亮点、能拿高分，还是得在几个地方下功夫——比如数据表设计的规范性、权限控制的完整性、图表统计的可视化呈现。这些在后面的章节里我都会逐一展开。

2. 业务需求分析与功能架构拆解

2.1 社区健康档案业务的核心痛点

在动手写代码之前，最好先想清楚一个问题：为什么社区卫生服务中心需要一个专门的老年人健康档案系统？直接用一个Excel表格不行吗？

还真不行。我调研过几个社区卫生服务站的日常业务流程，他们的档案管理痛点主要集中在三方面。

第一是信息维度多且分散。一份完整的老年人健康档案不仅仅包含姓名、身份证号、联系方式这些基础信息，还要记录既往病史、过敏史、家族病史、生活习惯（吸烟、饮酒、运动）、体检数据（身高、体重、血压、血糖、血脂）、慢病管理记录（高血压随访、糖尿病随访）等，一个大爷的完整档案往少了说也有二十多个字段。用Excel表去维护这种宽表，横向滚动非常痛苦，更不要说字段还经常要扩展。

第二是动态数据频繁更新。老年人不是体检一次就结束了，按国家基本公共卫生服务规范的要求，每年至少要提供一次健康体检，高血压和糖尿病患者还有季度或半年一次的随访要求。每条记录都要能追溯到时间点，这用Excel很难做规范，后面查某个老人的随访记录是否达标时更是要命。

第三是需要按条件检索统计。社区工作者经常要回答这类问题：我们这个辖区里患高血压的老人有多少？其中血糖也不正常的又有多少？上季度没来随访的有哪几个人？在Excel里做这种多维度的交叉统计，要么写复杂的函数公式，要么靠手工数，效率极其低下。

这套系统要解决的，就是这三个问题。它的核心数据模型围绕“居民基础信息 + 健康档案扩展信息 + 体检/随访动态记录”来设计，权限模型则划分管理员、医护人员和普通用户三个角色，分别管系统、管数据、管查看。功能上不贪大，但每一块都要落到业务实处。

2.2 功能模块划分与角色权限设计

整个系统的功能架构可以拆成六大模块：

• 登录与权限控制模块：基于Session的登录校验，配合拦截器对URL访问进行角色过滤。
• 居民信息管理模块：老年人基础档案的增删改查、条件检索、分页浏览，支持导入导出。这是整个系统的主数据。
• 健康档案管理模块：包括既往病史、过敏史、家族病史、生活习惯等健康信息的维护，可以理解为对基础档案的医学维度扩展。
• 体检记录管理模块：维护每次年度体检的数据，包括各项检查指标、体检日期、体检机构、异常项自动标记。
• 慢病随访管理模块：对高血压、糖尿病等重点慢病人群的随访记录进行管理，包括随访日期、随访方式、血压血糖数值、用药情况及医生建议。
• 数据统计与图表模块：按年龄段、性别、慢病类型、体检异常率等维度做统计，用图表展示辅助决策。

角色权限这里值得多说两句。很多学生做的毕设系统在权限这块就是走过场，前端藏个按钮就认为权限控制做好了，这是答辩时很容易被老师挑刺的点。合理的做法是：

• 管理员（admin）：拥有全部模块的操作权限，包括用户管理、数据删除、系统参数配置。
• 医护人员（doctor）：拥有居民档案、体检记录、随访记录的读写权限，但不能管理用户账号。
• 普通用户（elder）：绑定到某位具体老人，只能查看自己的档案和体检记录，只读，不可修改。

这个权限设计既贴合真实业务，又不会给开发带来过多负担。权限控制要在后端做，前端的菜单渲染只是锦上添花。后面第4章我会给出基于拦截器和角色字段的具体实现思路。

3. 技术选型解析：为什么是SSM而不是Spring Boot

3.1 SSM组合的职责边界与协作流程

讲SSM之前得先统一一个认知：SSM不是三个单独的工具，而是一个分工明确的协作框架。

• Spring是整个应用的大管家，负责管理对象（Bean）的创建和依赖关系。在SSM体系中，它主要承担Service层和DAO层的Bean管理、事务控制、数据源配置。
• Spring MVC负责Web层的请求分发，它接收浏览器发来的HTTP请求，根据URL找到对应的Controller方法去处理，再把处理结果渲染成JSP页面返回给浏览器。
• MyBatis负责数据库访问层的SQL映射。它允许开发者把SQL语句写在XML文件里，通过接口方法直接调用，避免了传统的JDBC样板代码，也保留了对SQL的完全控制权。

三者的协作流程可以用一次用户查询来串起来：浏览器发出一个想要查看某位老人档案的HTTP请求 -> Spring MVC的前端控制器DispatcherServlet拦截到这个请求 -> 根据映射关系转发给对应的Controller方法 -> Controller调用Service层的接口 -> Service层通过Spring注入的Mapper接口去调用MyBatis -> MyBatis根据XML中配置的SQL语句从MySQL中查出数据并封装成Java对象 -> 对象逐层返回 -> Controller把数据塞进Model -> 交给JSP模板渲染 -> 最终HTML页面回到浏览器。

这套链路看起来环节多，但恰恰是这种“层层分明”的写法，让项目里每个类的职责都非常清晰。答辩时你只需要按这个链路把代码指给老师看一遍，老师对你“系统架构是否理解到位”的判断，基本就有结论了。

3.2 选型对比：SSM、Spring Boot还是Spring Boot + MyBatis Plus？

很多同学在选题时会纠结一个问题：既然是2026年的毕设，为什么还要用SSM这种“老古董”？

我的观点是：毕业设计的首要目标是展示你的基本功，其次才是追求新技术。“老”不等于“不好”，SSM的教学资源丰富、踩坑贴多、老师熟悉，这些都意味着你做项目时的阻力和答辩时的风险都更低。

但我也理解大家“想要一个说得出口的技术亮点”的心情。如果你确实希望项目里带一点新东西，有两个“微调”方向可以参考，都不影响主体依然是SSM：

• 前端引入Vue或Element UI：后端依旧用SSM提供JSON接口，前端改成前后端分离的SPA页面。这个改动的工作量大约增加两周左右，但对视觉效果的提升是肉眼可见的，答辩时演示页面会好看很多。
• 图表库用ECharts：这套系统的数据统计模块不用自己造轮子画图，引入ECharts就能做折线图、饼图、柱状图，前端代码也不复杂，但对“系统功能完整性”的评价加成非常直接。

至于我个人的建议：如果时间充裕，可以在SSM主体完成后再考虑前端微调；如果时间紧凑，就踏踏实实把SSM这套跑通，把代码质量做扎实，把论文写规范。一个没有花架子的SSM项目，比一个半吊子的Spring Boot项目，答辩分数大概率更高。

3.3 开发环境与版本选型清单

开发现场直接给一份可复用的环境清单，版本都经过验证，互相之间没有兼容坑：

需要特别注意的是Spring、Spring MVC、MyBatis三者如果想要整合，版本不能乱配，建议直接在Maven坐标里加上spring-webmvc、spring-jdbc、mybatis-spring、druid这几个核心依赖。JDBC模板、数据库连接池这些组件配置要放在Spring的XML配置文件里，网上教程非常多，这里不展开。

4. 数据库建模与核心表设计

4.1 实体关系梳理与表结构清单

做数据库设计时，我的习惯是先画实体关系图再建表。这套系统的核心实体包括：用户（账号表）、居民（老人基础信息）、健康档案（扩展健康信息）、体检记录、随访记录、字典表（性别、慢病类型、随访方式等）。

它们的关系是：

• 一条居民记录对应一条健康档案记录（一对一）；
• 一条居民记录对应多条体检记录（一对多）；
• 一条居民记录对应多条随访记录（一对多）；
• 一个用户账号可以绑定一个居民（一对一，普通用户场景）。

基于这个关系，核心表清单如下：

• sys_user用户表：id、username、password、real_name、role、elder_id（绑定居民ID）、create_time
• elder_info居民信息表：id、name、gender、birth_date、id_card、phone、address、emergency_contact、blood_type、create_time、update_time
• health_profile健康档案表：id、elder_id、height、weight、smoke_status、drink_status、exercise_freq、past_history、allergy_history、family_history、remark
• physical_exam体检记录表：id、elder_id、exam_date、height、weight、blood_pressure_high、blood_pressure_low、blood_sugar、total_cholesterol、triglyceride、hdl、ldl、ecg_result、b_ultrasound_result、other_result、conclusion、exam_org
• follow_up慢病随访表：id、elder_id、follow_date、follow_type、disease_type、blood_pressure_high、blood_pressure_low、blood_sugar、medication、adverse_reaction、follow_advice、next_follow_date、doctor_name

4.2 关键字段设计要点与SQL示例

表设计里最容易被忽略但实际又非常关键的点，这里单独拎出来说：

第一，身份证号和姓名这类核心标识字段，建议加唯一索引。社区系统经常要录入重复数据，如果不做控制，一个人可能被录进系统两三次，后面统计数据就会虚高。在id_card字段上加UNIQUE索引，从源头卡住重复录入。

第二，所有时间字段建议使用DATETIME类型，并给出默认值CURRENT_TIMESTAMP。这样插入数据时不用手动处理时间，索引排序也方便。

第三，体检和随访中的血压、血糖值，建议存数值类型而不要存字符串。原因很简单，后面做“血压高于140/90的人数统计”时，字符串会彻底卡死你的SQL写法，而数值类型直接一条WHERE条件就搞定。

第四，推荐建一个字典表，把性别、疾病类型、随访方式这类可选值收进去。这样前端下拉框的数据从字典表动态加载即可，遇到要加一种随访方式的需求，不用改代码，直接加一条记录就行。

核心建表SQL示例（节选）：

CREATE TABLE `elder_info` ( `id` INT NOT NULL AUTO_INCREMENT, `name` VARCHAR(50) NOT NULL COMMENT '姓名', `gender` TINYINT NOT NULL DEFAULT 1 COMMENT '1男 2女', `birth_date` DATE NOT NULL COMMENT '出生日期', `id_card` VARCHAR(18) NOT NULL COMMENT '身份证号', `phone` VARCHAR(20) DEFAULT NULL, `address` VARCHAR(200) DEFAULT NULL, `emergency_contact` VARCHAR(50) DEFAULT NULL, `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_id_card` (`id_card`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='老年人基本信息表';

health_profile表用elder_id做外键关联elder_info，体检表和随访表同理。这里要注意外键约束可以建，但我个人建议在应用层通过elder_id的合法性校验来控制，而不是完全依赖数据库外键。原因很简单，后期做报表查询时JOIN操作更灵活，也不会因为外键约束导致删除数据时一堆报错。

5. 核心功能模块的实现与源码解读

5.1 登录与权限控制的完整实现

登录接口本身不难，难的是整个权限体系怎么在设计上自洽。我这里提供一个“账号表+角色字段+拦截器”的经典方案，各位可以直接在项目里复用。

第一步是登录Controller。核心逻辑是调用Service层的用户校验方法，成功后把用户对象放入Session：

@Controller public class LoginController { @Autowired private UserService userService; @PostMapping("/login") public String login(String username, String password, HttpSession session, Model model) { User user = userService.findByUsernameAndPassword(username, password); if (user == null) { model.addAttribute("msg", "用户名或密码错误"); return "login"; } session.setAttribute("loginUser", user); String role = user.getRole(); if ("admin".equals(role)) { return "redirect:/admin/index"; } else if ("doctor".equals(role)) { return "redirect:/doctor/index"; } else { return "redirect:/elder/index"; } } @GetMapping("/logout") public String logout(HttpSession session) { session.invalidate(); return "redirect:/login"; } }

第二步非常关键——在需要保护的URL上建立拦截器。你要有一个LoginInterceptor去判断Session里有没有用户，还要配合一个RoleInterceptor去校验角色有没有权限访问某个路径。

实际开发时，我习惯的做法是在Spring MVC的XML配置文件里配置拦截器：

<mvc:interceptors> <!-- 登录拦截器，拦截所有非登录页的请求 --> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/logout"/> <mvc:exclude-mapping path="/static/**"/> <bean class="com.project.interceptor.LoginInterceptor"/> </mvc:interceptor> <!-- 角色拦截器，对特定角色开放的路径走角色校验 --> <mvc:interceptor> <mvc:mapping path="/admin/**"/> <bean class="com.project.interceptor.AdminInterceptor"/> </mvc:interceptor> </mvc:interceptors>

这里的思路是：所有除登录页之外的请求，先经过登录拦截器判断是否已经认证；再去按URL前缀做角色的二次校验。这样做的好处是Controller代码里完全不需要写权限判断，业务逻辑干干净净。

踩坑提示：不走拦截器的“漏网之鱼”是最常见的权限漏洞。排查时对照你的所有Controller的@RequestMapping和<mvc:mapping>配置一条条手工过一遍，尤其注意不要漏掉静态资源目录的排除配置。

5.2 居民健康档案的CRUD与分页检索

居民信息是整个系统的主数据，每天的日常操作都围绕它展开。多条件检索加翻页是这个模块功能上的核心，实现方式上我推荐使用PageHelper这个MyBatis插件。

Maven引入：

<dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper</artifactId> <version>5.1.11</version> </dependency>

然后在Spring配置里注入分页拦截器插件，之后在Service层查询前调用PageHelper.startPage(pageNum, pageSize)，后面的查询就会自动带上LIMIT语句。具体代码体现为：

@Override public PageInfo<ElderInfo> searchElder(String name, String gender, String diseaseType, int pageNum, int pageSize) { // 开启分页，紧接着的第一次select会被自动分页 PageHelper.startPage(pageNum, pageSize); List<ElderInfo> list = elderInfoMapper.searchByCondition(name, gender, diseaseType); return new PageInfo<>(list); }

Mapper对应的SQL在XML文件里这样写（注意用<if>动态标签拼接条件）：

<select id="searchByCondition" resultType="com.project.entity.ElderInfo"> SELECT e.*, h.disease_type FROM elder_info e LEFT JOIN health_profile h ON e.id = h.elder_id <where> <if test="name != null and name != ''"> AND e.name LIKE CONCAT('%', #{name}, '%') </if> <if test="gender != null and gender != ''"> AND e.gender = #{gender} </if> <if test="diseaseType != null and diseaseType != ''"> AND h.disease_type = #{diseaseType} </if> </where> ORDER BY e.create_time DESC </select>

这里有两个很容易犯错的地方。第一，PageHelper.startPage必须紧跟第一条查询语句，中间不能插入其他查询，否则分页条件会被加到错误的SQL上。第二，用LIKE CONCAT('%', #{name}, '%')而不是在Java代码里拼好%再传入，这样可以避免SQL拼接的安全隐患。

体检记录和随访记录的增删改查套路与此高度一致，核心都是“以elder_id作为外键关联查询 + 按日期倒序”。你只需要把Elder换成Exam或者FollowUp，页面表单换成对应的字段，一套完整的业务链就长出来了。

5.3 数据统计模块的SQL思路与图表展示

这一块是最能体现“需求分析到位”的模块。比如统计不同年龄段（60-69、70-79、80+）的老人人数，一条SQL就能完成：

SELECT CASE WHEN TIMESTAMPDIFF(YEAR, birth_date, CURDATE()) < 70 THEN '60-69' WHEN TIMESTAMPDIFF(YEAR, birth_date, CURDATE()) < 80 THEN '70-79' ELSE '80+' END AS age_group, COUNT(*) AS cnt FROM elder_info GROUP BY age_group;

再比如想统计高血压人群的性别分布：

SELECT gender, COUNT(DISTINCT e.id) AS cnt FROM elder_info e JOIN health_profile h ON e.id = h.elder_id WHERE h.disease_type LIKE '%高血压%' GROUP BY gender;

这些SQL在MySQL命令行里先验证一遍，确认结果没问题后再搬到Mapper的XML里。这步验证特别重要，因为很多同学在MySQL中直接把中文条件写到了SQL里，可能因为字符集问题查不出数据，搬到项目里调试了半天才发现。

图表展示的前端部分，我的推荐方案是ECharts。在JSP页面中引入ECharts的CDN或者本地echarts.min.js，然后通过Ajax从后端获取统计数据，用它来渲染柱状图（各年龄段分布）、饼图（慢病类型占比）、折线图（年度体检人数变化）。代码不算复杂，核心只需三步：

// 1. 发起Ajax请求获取统计接口返回的JSON数据 $.get('/statistics/ageDistribute', function(data) { // 2. 初始化图表并配置option var chart = echarts.init(document.getElementById('mainChart')); chart.setOption({ title: { text: '老年人年龄分布统计' }, tooltip: {}, xAxis: { data: data.categories }, yAxis: {}, series: [{ type: 'bar', name: '人数', data: data.values }] }); });

注意后端返回JSON时要用@ResponseBody注解或@RestController，并且实体类必须有getter方法，否则Jackson序列化时会直接报空指针或者返回空对象。这个错误实在太多人踩了，我先在这里提个醒。

6. 循序渐进：从环境搭建到功能联调

6.1 项目骨架初始化与依赖引入

整套系统的开发流程，我建议按照“环境 -> 骨架 -> 数据表 -> 登录 -> 基础CRUD -> 扩展模块 -> 图表”的节奏推进。不要想着把每一个细节都研究透了再动手，先让系统跑起来，能出一个页面就算阶段性胜利。

第一步，用IDEA新建一个Maven项目，选择maven-archetype-webapp骨架，然后在pom.xml里声明父依赖版本、核心依赖和插件。这一步坑比较多的是依赖版本冲突。比如spring-webmvc声明的是5.2.x，结果mybatis-spring用的是2.1.x，两者之间按说没问题；但如果用到了spring-jdbc的@Transactional注解，就必须确保声明了spring-tx依赖，否则在Service类上写事务注解时编译都过不了。

推荐直接复制下列完整依赖清单的第一版起步，后续再根据实际需求增删：

<dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>5.2.15.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> <version>5.2.15.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-tx</artifactId> <version>5.2.15.RELEASE</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.8</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>2.0.6</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.49</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.2.8</version> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.2</version> </dependency> <dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper</artifactId> <version>5.1.11</version> </dependency> </dependencies>

6.2 三层结构目录规划与配置解析

项目内部的包结构，我建议按这个模板来组织：

com.project ├── controller // Web控制层：接收请求、返回视图 ├── service // 业务接口层：定义业务方法 │ └── impl // 业务实现层：写具体逻辑 ├── mapper // MyBatis Mapper接口 ├── entity // 数据库实体类，与表字段一一对应 ├── interceptor // 登录/角色拦截器 ├── config // 配置类（如数据源、拦截器注册） ├── util // 通用工具类 └── common // 统一返回结果、常量、异常处理类

SSM项目的核心配置分为三个文件：spring-context.xml（Spring主配置，管理Service与Mapper）、spring-mvc.xml（Spring MVC配置，管理Controller与视图解析器）、mybatis-config.xml（MyBatis配置），再加上一个jdbc.properties存放数据库连接信息。

配置要点有几个。数据源建议用Druid连接池，配置initialSize为5，maxActive为20，minIdle为5，这些参数在内网小并发场景下足够用，不会触发性能问题。事务管理用DataSourceTransactionManager，然后在Service实现类上标注@Transactional即可。Mapper扫描有两种方式：要么在Spring配置中配置MapperScannerConfigurer，要么用<mybatis:scan>标签，指定base-package为com.project.mapper，这样所有Mapper接口都会被Spring自动代理注册。

其中最容易出错的是实体类与表字段的映射关系。如果数据库字段用了下划线命名（如create_time），而Java属性是驼峰命名（如createTime），MyBatis需要在配置中开启驼峰命名映射：

<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings>

这个配置漏了，你会发现查出来的数据里时间字段全是null。类似的坑后面遇到会继续补充。

6.3 页面设计与交互流程串联

SSM项目的页面由JSP承担，实战下来我建议用JSP+JSTL+EL表达式这套组合，前端用Bootstrap的栅格布局和CSS组件来画页面。页面文件放在webapp下的WEB-INF/views/目录，这样外部无法直接通过URL访问，只能通过Controller转发渲染。

页面整体风格走“简洁医疗风”——主色调建议用蓝色或绿色系的浅色背景，正文用深灰色，卡片用白色圆角发阴影。不要整大红大紫，跟医疗场景气质不符，答辩时老师看了印象也不太好。

页面跳转流程用一次“录入体检记录”来串联：管理员在列表页点击“新增体检” -> 跳转到/exam/toAdd?elderId=xxx-> Controller把老人ID传递给JSP页面 -> 表单提交到/exam/add-> Controller调用Service保存数据 -> 重定向回/exam/list?elderId=xxx，列表上刷新出最新一条体检记录。

JSP页面里要注意利用JSTL标签遍历列表数据，不要用Java脚本片段嵌套写死。例如：

<c:forEach items="${pageInfo.list}" var="elder"> <tr> <td>${elder.name}</td> <td>${elder.gender == 1 ? '男' : '女'}</td> <td><fmt:formatDate value="${elder.birthDate}" pattern="yyyy-MM-dd"/></td> <td> <a href="/elder/detail/${elder.id}">详情</a> <a href="/elder/toEdit/${elder.id}">编辑</a> </td> </tr> </c:forEach>

fmt:formatDate这个JSTL标签要记得引入<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>，否则页面直接白屏或者无法编译，这是新手常见问题。

6.4 从源码到论文：文档撰写的高效路径

这系统带源码和论文，论文稿子咱们也得讲究效率。我的建议是：代码编写与论文撰写平行推进，不要等项目代码全写完再动笔。

推荐论文结构：

• 第一章 绪论：选题背景（人口老龄化+公共卫生服务信息化）、国内外研究现状、研究内容与目标
• 第二章 相关技术介绍：Java、SSM框架、MySQL、前端技术、开发工具
• 第三章 系统分析：可行性分析、需求分析（功能需求+非功能需求）、用例图
• 第四章 系统设计：总体架构设计、功能模块设计、数据库设计（含E-R图和表结构）
• 第五章 系统实现：每个模块的界面截图+核心代码段+关键逻辑说明
• 第六章 系统测试：测试环境、测试用例设计、功能测试结果、性能简单验证、结论

关于测试章节，建议大家做一个最基本的测试用例表格，列清楚：测试编号、测试项、操作步骤、预期结果、实际结果、是否通过。这样整节内容非常扎实，而且不需要任何自动化测试工具，纯手工自测数据就能填满整整三页表格。答辩老师翻到这一页最轻松，印象也最好。

我个人非常推荐用Visi或PlantUML直接画E-R图和数据流图入库到论文第四章，不要用Word画图。不然论文进度会浪费大量时间在图形的美观调整上。

7. 开发全过程常见痛点与排查方案

7.1 环境与框架层面的高频踩坑

问题1：Tomcat启动后访问8080直接404。

排查思路：先看Maven依赖是否全部下载完毕，再看项目有没有真正部署到Tomcat。IDEA里部署Web项目需要配置Web Application: exploded这种Artifact，右键项目 -> Open Module Settings -> Artifacts -> 新建Web Application Exploded。另外检查web.xml里DispatcherServlet的<url-pattern>配置，如果是*.do，那访问URL就要带.do后缀，否则自然404。

问题2：Mapper接口注入降级或报Invalid bound statement (not found)。

几乎每个初学SSM的人都踩过这个坑。这个报错的含义是Spring容器里有Mapper接口的Bean，但MyBatis没有找到对应的XML映射文件。常规原因有三个：一是XML文件的namespace与接口全限定名不一致；二是XML文件的id与接口方法名不一致；三是XML文件没有放在mapper包对应的资源路径下（Maven默认只复制src/main/resources下的文件，如果你把XML放在java目录下，就需要在pom.xml的build中配置resources）。

最省心的做法是把所有Mapper XML统一放在resources/mapper/目录下，然后在mybatis-config.xml里配置：

<mappers> <package name="com.project.mapper"/> </mappers>

或者用Spring配置的MapperScannerConfigurer时设置basePackage，并确保XML的路径可以被扫描到。

问题3：登录页可以打开，但提交登录请求后进入500错误。

先看控制台错误日志。最常见的报错是BadSqlGrammarException，说明SQL语句语法有问题，去MySQL命令行把这条SQL手工跑一遍即可定位。其次是ClassNotFoundException问题，典型的如缺少MySQL驱动依赖。

问题4：中文乱码。

这是毕设系统里最经典的翻车现场。方向有两个：一是检查数据库连接URL是否显式设置了characterEncoding=utf8：

jdbc.url=jdbc:mysql://localhost:3306/health?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

两个关键是——MySQL 5.7的数据连接URL不需要serverTimezone参数，MySQL 8.0则必须加。第二个是检查JSP页面page指令里是否声明UTF-8，表单提交时浏览器端也需要使用UTF-8编码。这三个位置必须一致，否则前端输入中文传回后端后端识别不出来。

7.2 业务逻辑层的隐性坑位

问题1：数据统计出来翻倍。

典型场景：用JOIN连接健康档案表和体检表统计人数时，如果一个老人有多条体检记录，JOIN后会产生笛卡尔积效果，导致COUNT出来的数值远超实际人数。解决方案要么用COUNT(DISTINCT e.id)，要么先在一张表上分组统计再JOIN。这条SQL意识只靠调试也可能发现不了，需要建立“多表JOIN计数必查重复”的防御性思维。

问题2：删除功能时报外键约束错。

如果是业务上允许删除一个老人，那么需要同时删除其健康档案、体检、随访等关联数据。我建议在Service层把它们放进一个事务方法中，用@Transactional包裹，顺序删除。删除前先做确认提示框，后端再校验一次是否存在关联引用。

问题3：时间数据在MySQL和Java之间的类型错了。

DATETIME在Java中对应java.util.Date，在MyBatis的映射关系中直接用即可。但如果你把birth_date设置成了DATE类型，Java实体属性还用的java.sql.Date，后面做格式化时会多出麻烦。统一建议：所有日期字段全部用java.util.Date配合@DateTimeFormat(pattern = "yyyy-MM-dd")接收前端日期字符串，JSP输出时用<fmt:formatDate>来格式化。

问题4：Session里存了用户但页面不显示登录状态。

在JSP中用${sessionScope.loginUser.name}这种方式取值是常见写法。如果取不到值，优先确认登录成功之后确实执行了session.setAttribute，再看看页面引用的路径是否因为多了一层目录导致取的属性没了。最有效的排查方法是在JSP临时加一行${sessionScope}打印整个Session里的所有键值，一眼就知道存没存进去。

8. 答辩准备与项目加分策略

8.1 演示前要跑通的核心链路

答辩演示的前一天，建议收敛演示路径，不要面面俱到，因为时间有限。我的建议是重点走以下五条链路：

第一条，管理员登录，录入一位老人基本信息并创建健康档案（展示新增与绑定逻辑）。

第二条，新增一条体检记录，故意把血压值填高，展示异常数值的标记功能，并说明这对接了慢病高危人群的筛选逻辑。

第三条，给这位老人新增一条高血压随访记录，然后在统计分析模块中按疾病类型筛选，展示图表中出现了高血压相关的数据点。

第四条，演示权限控制：退出后用医护人员账号登录，尝试访问管理员专属的URL（比如/admin/userList），展示拦截器如何拒绝访问并跳转到无权限提示页。

第五条，展示多条件检索效果：按年龄段+高血压条件组合筛选，快速定位目标人群，强调这对社区医生高效管理重点人群的实际价值。

每走一条链路，都准备好一两句解释词：“这里我使用了PageHelper分页插件”、“这里我通过Druid连接池管理数据库连接”、“这里我用ECharts展示了趋势变化”。这样整场演示就是有节奏、有深度的。

8.2 老师偏爱的追问方向与应答思路

答辩老师常见追问，我按出现频率整理并给出合适的应答参考：

• 问：为什么选择SSM而不是Spring Boot？

参考答法：SSM是Spring技术栈的经典组合，相比Spring Boot更贴近底层，能体现我对Spring IOC/AOP、Spring MVC请求流程和MyBatis映射原理的理解。Spring Boot确实提高了开发效率，但它的自动配置内部细节容易被忽略。作为毕业设计，我选择SSM更多是为了夯实基础，同时也保留了后续向Spring Boot迁移的可能性。

• 问：你的权限控制是怎么做的？

参考答法：用户角色存在用户表的role字段中，登录成功后写入Session。通过Spring MVC的拦截器对URL进行拦截校验，管理员路径/admin/**只有role为admin的用户可以访问，普通用户只能访问查看类接口。这样即使有人绕过前端页面直接拼接URL，也无法访问到未授权的功能。

• 问：如果老年人数量非常大，系统性能怎么保证？

参考答法：目前系统基于分页查询和索引设计，在id_card、birth_date等字段建立了索引，大数据量场景下主要查询走的索引。如果将来用户量进一步增长，可以引入Redis做热点数据缓存，把列表查询移到缓存中；数据库层面可以按社区分区，或者做读写分离。这是比较合理的演进路径。

• 问：系统的安全性方面做了哪些处理？

参考答法：登录密码现在用的是MD5加密存储（如果时间充裕建议换成BCrypt），数据访问层采用预编译SQL防注入，前端页面做了简单的XSS字符过滤。如果有精力，还可以加上登录验证码和操作日志记录，不过这两个是加分项，不是必要条件。

8.3 提升分数的小改动

如果代码主体和论文都已完成，且还有剩余两三天，我推荐做这几个低成本高回报的改动：

第一，做好统一异常处理。用@ControllerAdvice配合@ExceptionHandler写一个全局异常拦截器，让系统报错时不再显示大片红色异常栈，而是跳转到友好错误页。这一点答辩时演示一下非常加分，因为它直接体现了工程化意识。

第二，把登录成功后的首页加上仪表盘：展示辖区老人总数、今日新增档案数、高血压人数、待随访人数。数据全来自现有表，前台用一组统计卡片加上一个饼图即可，半天工作量，但首屏演示效果完全不同。

第三，密码存储从明文改成加密模式。很多SSM毕设还是明文密码，虽然演示时没人在意，但老师只要问一句“你的数据库密码安全吗”，场面就会很被动。哪怕只是用Spring自带的DigestUtils.md5DigestAsHex做一次哈希，也算有交代。

9. 后续演进方向与我的个人体会

做完整套SSM项目之后，如果还有精力和动力，其实可以给它规划几条清晰的演进路径。最自然的方向是把后端从SSM迁移到Spring Boot，同时将接口改造成RESTful风格，前端页面换用Vue3 + Element Plus，实现前后端分离。数据访问层可以替换为MyBatis Plus这一套，配合代码生成器可以快速产出基础CRUD代码。数据库层面考虑引入Redis缓存体检热数据和定期随访筛选结果，降低MySQL的查询压力。

后台管理如果希望更专业，可以增加操作日志和登录日志模块，记录每个用户的关键操作，审计追溯都有依据。对于慢病随访这个核心业务，也可以增加随访计划自动提醒功能——根据上次随访日期和随访周期（比如90天）自动生成待随访名单，在首页里推送提醒，这样系统就从“被动记录”升级到了“主动管理”。

就我个人反复做这类JavaWeb毕设项目的体会而言，SSM这套东西最大的价值不在于框架本身有多先进，而在于它能逼着你把Web开发的一条主线全部摸一遍：请求怎么进来、参数怎么绑定、事务怎么控制、SQL怎么映射、页面怎么渲染、异常怎么处理。这一条主线走通，后面学什么框架都只是换道具的事。

最后分享一个开发过程中的小技巧：写代码的顺序不要按照前端到后端走，而是反过来，从数据库表设计开始，然后是实体类、Mapper、Service、Controller，最后才是页面。这个顺序能让每一层的接口都清晰可测，每完成一层就能用Postman或者浏览器验证一层，远比先写一堆JSP再去对后端舒服得多。我做过多届类似项目，只要有同学抱怨“代码写乱了”，绝大多数都是因为顺序搞反了。

这套社区老年人健康档案管理系统的完整代码和论文框架，其实大家在开源平台和毕设辅助站点搜“SSM健康档案管理”能找到很多可参考的版本，但参考归参考，自己照着搭一遍、跑一遍、填一遍数据、改一遍样式，才能真正把它变成答辩时聊得清楚的东西。祝各位都能顺利过审。