基于SSM的社区疫情管理系统设计与实现

1. 选题背景与核心需求拆解

先说结论：基于SSM的社区疫情管理系统，这个选题放在计算机毕业设计里，属于典型的"业务场景清晰、技术栈经典、工作量适中"的项目类型。我用这个词在技术社区里搜了一圈，发现近几年做这个方向的同学不在少数，说明它确实踩中了毕业设计的几个核心诉求——有真实业务逻辑可讲、有完整CRUD可写、有权限和数据可视化可展示，而且答辩时不需要费劲解释"这个系统到底解决什么问题"。

1.1 这个系统到底解决什么问题

疫情管理系统拆开来看，核心就一句话：让社区管理人员能够高效地收集、跟踪、统计居民的健康与出行信息，并在出现异常时快速预警和处置。

在没有这类系统之前，社区工作者的日常是大量靠微信群接龙、Excel表格汇总、电话逐个通知。居民每天手动填写体温和行程，社区人员再手动录入电脑，信息分散在不同聊天记录和文件里，想查一个人的历史记录要翻半天聊天记录，想统计整个社区的疫苗接种率得手工合并N个Excel表。这套流程的痛点非常明确：

• 数据分散，缺乏统一存储和检索手段
• 统计靠人工，容易出错且效率低
• 异常信息不能及时触达管理人员
• 居民、工作人员、管理员之间缺乏清晰的角色边界和操作权限

而基于SSM的社区疫情管理系统，正是用Web技术把这些线下流程搬到线上：居民用浏览器就能完成每日健康打卡和出入登记，工作人员后台实时查看异常数据、管理隔离人员、安排物资配送，管理员统一配置社区网格和账号权限。整个数据闭环走下来，系统覆盖面就非常完整了。

1.2 为什么选SSM而不是Spring Boot

很多同学在选题时会纠结："现在企业都用Spring Boot了，SSM是不是过时了？"这个问题我在实际指导学生做项目时几乎每次都会被问到。

我的建议很明确：如果目标是毕业设计，SSM不但不过时，反而是更稳妥的选择。原因有三：

第一，SSM指Spring + SpringMVC + MyBatis，它是Spring技术体系里最经典的组合，Spring Boot本质上也是对这套框架的自动化封装。把SSM的原理吃透了，理解Spring Boot只会有更顺滑，答辩时老师问底层原理你完全接得住。

第二，SSM需要手写大量XML配置和注解，这个过程虽然繁琐，但恰恰能体现出你对框架运行机制的理解。毕业设计的评分维度里有一条就是"技术深度"，你能说清楚Spring IoC容器如何管理Bean、SpringMVC的DispatcherServlet如何分发请求、MyBatis的Mapper代理如何生成SQL，这比"我用Spring Boot一键生成项目"在答辩中更有说服力。

第三，SSM整合方案非常成熟。网上资料多、坑少，遇到问题能快速找到解决方案，对于开发经验不足的同学来说，意味着可控的风险和进度。毕竟毕业设计拼的不是炫技，而是稳定交付。

注意：如果你前期已经学了Spring Boot，也完全可以在这个系统里改用Spring Boot + MyBatis，架构思路和本篇文章的模块划分完全通用，只是少了配置部分的篇幅。但我下面讲的内容仍以SSM为准，方便你对照经典配置来理解。

2. 系统整体架构与数据库设计

2.1 架构分层设计

这套系统的架构我建议严格遵循SSM的标准分层方式：表现层（Controller）、业务层（Service）、数据访问层（Mapper/Dao）三层结构，再加上实体类（Entity/VO）、工具类（Util）和公共配置（Config）。

为什么要分这么细？因为疫情管理系统的业务逻辑天然就带有多角色协作的特点——居民端操作是高频低复杂度，工作人员端是中等复杂度的信息审核和跟踪，管理员端是低频但敏感度高的配置管理。如果不做分层，角色功能交织在一起，后期扩展一个"核酸点排队人数上报"功能可能都要动一堆代码。

我给出的实际包结构如下：

com.community.epidemic ├── controller │ ├── LoginController.java │ ├── UserController.java │ ├── HealthCheckController.java │ ├── TravelRecordController.java │ ├── IsolationController.java │ ├── MaterialController.java │ ├── StatisticsController.java ├── service │ ├── IUserService.java │ ├── IHealthCheckService.java │ ├── ITravelRecordService.java │ ├── IIsolationService.java │ ├── IMaterialService.java │ └── impl ├── mapper │ ├── UserMapper.java │ ├── HealthCheckMapper.java │ ├── TravelRecordMapper.java │ └── ... ├── entity │ ├── User.java │ ├── HealthCheck.java │ ├── TravelRecord.java │ ├── IsolationInfo.java │ └── ... ├── interceptor │ └── LoginInterceptor.java ├── util │ └── ... └── config └── SpringMVCConfig.java / MyBatisConfig.java

这套结构我在"模拟项目X"（某社区网格化管理Demo）里验证过完整走通，放在这个系统上完全兼容。需要注意的是，Controller层尽量不要写业务逻辑，只负责参数接收、简单校验、调用service然后返回视图或JSON；Service层负责事务边界和方法粒度控制；Mapper层尽量做到一个方法对应一条SQL，减少复杂关联查询的维护难度。

2.2 数据库表结构设计

数据库设计是这类系统最见功底的部分。疫情管理系统的核心实体包括：居民用户、每日健康打卡记录、出行登记记录、隔离管理记录、物资配送记录、系统管理员/工作人员账号。

我最推荐的实践是围绕业务行为建表，而不是围绕角色建表。什么意思？就是不要把"居民信息""员工信息"硬拆成两张表，而是统一放在用户表（t_user）中，用role字段来区分类型。这样设计的好处是整个系统的用户身份校验只需要走一套登录逻辑，个人信息维护也只需要一个接口，做分页查询时还能按角色过滤，一个通用方法通吃。

下面给出核心表的参考设计：

t_user（用户表）

t_health_check（健康打卡表）

t_travel_record（出行登记表）

t_isolation（隔离管理表）

除此之外，t_material（物资配送表）记录隔离人员物资需求与配送状态，字段包含user_id、item_name、item_count、delivery_date、status；t_notice（公告表）用于社区发布通知，包含title、content、publish_time、publisher_id。

在设计id_card时建议直接使用varchar而不是bigint，因为身份证号存在X，而且超过bigint的可读范围，这一点是很多新手容易忽略的。

2.3 表关系与关键外键约定

这套系统的表关系相对简单清晰：

• 一个用户每天可以有多条健康打卡记录，但逻辑上同一用户同一天只能有一条"有效"记录（通过check_date + user_id做联合唯一索引约束）
• 一个用户可以有多次出行登记记录
• 一个用户同一时间段通常只有一条"进行中"的隔离记录

这里我强烈建议在表结构设计阶段就做一层"唯一约束 + 索引"的优化。特别是健康打卡表，加上UNIQUE KEY uk_user_date (user_id, check_date)，这样在并发提交时数据库层面就能挡掉重复数据，而不是靠Java代码判断。这个细节做好了，答辩时就能主动讲出"我考虑了并发场景下的数据一致性"，加分效果明显。

3. 核心功能模块设计与实操实现

3.1 登录与权限拦截

用户登录这块，技术上不复杂，但有两个点值得做好：

第一，密码不能明文存储。毕业设计里很多人偷懒直接存明文，答辩时如果老师问"这个系统的安全性体现在哪里"就会卡壳。至少用MD5加盐，或者直接引入Shiro做一个简单的认证授权。用MD5加盐实现大概十行代码，不需要引入额外依赖：

public static String encrypt(String password, String salt) { String base = password + salt; return DigestUtils.md5DigestAsHex(base.getBytes(StandardCharsets.UTF_8)); }

第二，登录状态用Session + 拦截器管理。SSM里实现未登录拦截，标准做法是写一个拦截器，在preHandle方法里检查Session中是否存在登录用户，如果没有就重定向到登录页：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }

然后在SpringMVC配置中注册拦截器，同时配置静态资源和登录接口进行放行。角色权限的区分可以在拦截器基础上再判断一下session里的user.role，比如管理员访问后台管理界面，工作人员访问数据操作接口，居民只能访问自己的数据。这里我建议用基于角色的URL访问控制，比如/admin/开头的地址只允许role=3访问，/staff/开头的只允许role=2或3访问。实现方式可以写一个RoleInterceptor或者在Controller方法上加自定义注解，简单场景下直接在拦截器里判断路径前缀就够用。

3.2 居民端功能模块详解

居民端是这套系统使用频次最高的部分，核心功能包括：每日健康打卡、个人出行登记、查看社区公告、个人信息维护。

每日健康打卡是典型的新增操作，前端一个表单页，包含体温（decimal类型输入）、是否咳嗽（radio）、是否乏力（radio）、是否接触史（radio）、健康码状态（select）等字段。提交后后台做两件事：写入t_health_check表，同时根据规则判断是否触发异常逻辑——比如体温超过37.3度，或者有接触史，那么自动将用户状态标记为"需关注"，并在工作人员待办列表中生成一条预警记录。

这块业务逻辑的判断我放在Service层实现：

@Transactional public int submitHealthCheck(HealthCheck check) { // 1. 判断当天是否已打卡，防重复 HealthCheck exist = healthCheckMapper.selectByUserIdAndDate( check.getUserId(), check.getCheckDate()); if (exist != null) { throw new BusinessException("今日已打卡，请勿重复提交"); } // 2. 插入打卡记录 healthCheckMapper.insert(check); // 3. 体温异常或接触史为是时，更新用户状态并插入预警 boolean abnormal = check.getTemperature() >= 37.3 || check.getIsContact() == 1; if (abnormal) { userMapper.updateStatus(check.getUserId(), 2); warningMapper.insert(...); // 预警记录 } return check.getId(); }

这里必须加@Transactional注解，确保打卡记录和用户状态更新同时成功或同时失败。我在实际测试中就遇到过一种情况：打卡记录写入成功，但更新用户状态时报错，如果没有事务，就会出现"数据不一致"的bug。

出行登记相对简单，一个insert操作加一个用户维度的列表查询。但有一个实操细节值得注意：出行记录往往需要支持"是否返回"状态的更新，也就是居民从外地回来之后要登记返回信息，这时用MyBatis的update操作，按id更新指定字段。可以单独做一个返回接口，而不是让居民修改整条记录。

3.3 工作人员端功能模块详解

工作人员端是后台管理的重心，核心功能包括：健康数据审核与预警处理、隔离人员管理、物资配送管理、公告发布管理。

健康数据审核这里我做的不是"人工逐条审核"，而是"系统自动判定 + 人工复核"，这样更贴近实际操作。系统把所有打卡记录按状态分成两类：正常记录和异常记录。异常记录默认进入"待处理列表"，工作人员看到后可以联系居民确认情况，然后将状态改为"已处理并备注原因"。这样做的好处是避免漏掉异常数据，同时不给工作人员增加太多无意义的审核负担。

隔离人员管理模块，工作人员可以选择用户（通常是状态被标记为异常的居民），设定隔离起止日期、隔离类型（居家或集中）、负责联系人，然后该用户的健康打卡页面会自动进入隔离模式——界面上会有醒目的"居家隔离中"标识，且出行登记功能被锁定。

这里需要强调一个设计细节：隔离状态不要直接硬编码成用户表里的状态位，而是通过查询隔离记录表来判断。因为隔离是一个时间段概念，有开始时间和结束时间，单纯一个status=1无法区分"已解除隔离"和"还没开始隔离"。我当时写过这样一个查询逻辑：

public IsolationInfo getActiveIsolation(Integer userId) { IsolationInfo info = isolationMapper.selectByUserIdAndStatus(userId, 0); if (info == null) return null; // 判断隔离是否已到期 if (info.getEndDate().before(new Date())) { isolationMapper.updateStatus(info.getId(), 1); // 自动解除 return null; } return info; }

每次查询用户信息时，调用这个方法动态判断用户当前是否处于隔离期，比维护一个冗余状态位要可靠得多。这个思路在答辩时稍微展开讲一下，就能体现你对于"业务状态应该由行为数据推导，而不是冗余存储"这个原则的理解。

物资配送管理算是这个系统里比较有社区特色的一块。隔离人员不能出门，生活物资需要工作人员配送。系统做一个"居民申请物资——工作人员处理配送——标记送达"的闭环流程，对应t_material表的三个状态。这块不复杂，但这个闭环流程的存在让整个系统的业务完整性提升了不少。

3.4 管理员端功能模块详解

管理员端主要负责三个事情：用户账号管理、社区基础数据管理（如网格/楼栋信息）、数据统计可视化。

用户账号管理就是常规的增删改查，但要注意删除操作一般不做物理删除，而是用status字段做逻辑禁用。因为健康打卡、出行记录这些历史数据都关联着用户id——包括身份证号等个人信息，假删除永远比真删除稳妥，这也是数据合规层面的一个基本常识。

数据统计面板是答辩时最能出效果的部分。我通常建议至少做三个维度的统计：每日健康打卡率、异常体温人数与趋势、隔离人员数量与分布。用MyBatis查聚合数据，Controller返回JSON，前端用ECharts生成柱状图、折线图和饼图。最多写100行前端JS的事情，却能极大提升整系统的完成度。

比如"近7天每日打卡人数"这个图表的SQL：

SELECT check_date, COUNT(DISTINCT user_id) AS check_count FROM t_health_check WHERE check_date BETWEEN DATE_SUB(CURDATE(), INTERVAL 6 DAY) AND CURDATE() GROUP BY check_date

需要注意MyBatis里关于日期参数的传递，如果前端传的是字符串，直接#{date}即可，数据库里用DATE类型字段接收。如果要在Mapper的XML里写动态日期计算，建议直接用数据库函数（如上所示的DATE_SUB），避免Java端和数据库端时区不一致导致边界问题。

3.5 SSM整合关键配置参考

既然题目明确要求SSM，我这里直接把整合过程中最容易出问题的几个配置点摆出来，同学们可以直接抄作业。

Spring配置文件（applicationContext.xml）主要管数据源、SqlSessionFactory、事务管理器和组件扫描。数据源我用的是Druid连接池，配置里别忘记指定数据库驱动、URL、用户名和密码。SqlSessionFactory需要关联MyBatis的全局配置文件和Mapper XML位置的属性：

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="typeAliasesPackage" value="com.community.epidemic.entity"/> </bean>

如果有MyBatis的全局配置文件，比如开启驼峰映射，在configuration属性下面用configLocation指向。驼峰映射这一个配置强烈建议开启，否则real_name映射到realName需要手动写resultMap，没开启的话你会被各种字段映射错误折磨到怀疑人生。

SpringMVC配置文件（spring-mvc.xml）主要管包扫描、注解驱动和视图解析器。用JSP做视图的话，视图解析器的prefix和suffix配置为/WEB-INF/jsp/和.jsp。注意一个常见坑：静态资源如CSS、JS、图片要配置<mvc:default-servlet-handler/>，否则样式全丢。另一个常见坑是注解驱动不要漏，漏了@RequestMapping完全无法生效。

web.xml中需要配置DispatcherServlet和Spring的监听器ContextLoaderListener。DispatcherServlet的init-param要指到spring-mvc.xml。同时记得增加CharacterEncodingFilter来统一编码，否则插入数据库的中文会产生乱码。这三个配置文件的协作关系我在"某跨平台系统"项目中也踩过差不多的坑，整合好之后就是SSM三板斧——Spring管对象、SpringMVC管请求、MyBatis管数据。

4. 核心功能实现细节与代码示例

4.1 使用MyBatis与控制器实现后台人员管理

后台人员管理是最典型的CRUD块，但写的时候有一点值得留意——分页查询最佳实践。SSM中实现分页，我推荐直接使用PageHelper插件，引入依赖后在配置里添加拦截器，然后在Service层做：

public PageInfo<User> getUsers(int pageNum, int pageSize, User quer) { PageHelper.startPage(pageNum, pageSize); List<User> list = userMapper.selectByCondition(quer); return new PageInfo<>(list); }

PageHelper的原理是拦截下一次执行的SQL，自动拼接LIMIT。实际开发中要注意：PageHelper.startPage()之后必须紧跟着执行一条Mapper查询，中间不能有其他数据库操作，否则分页会作用在错误的SQL上。这个坑我见很多同学踩过。

在controller层接收参数时，可以直接用User对象接收前端多字段查询参数，然后传给service。查询条件中如果涉及到模糊查询，比如用户姓名，XML中的写法是：

<select id="selectByCondition" resultType="User"> SELECT * FROM t_user <where> <if test="realName != null and realName != ''"> AND real_name LIKE CONCAT('%', #{realName}, '%') </if> <if test="role != null"> AND role = #{role} </if> <if test="community != null and community != ''"> AND community = #{community} </if> </where> ORDER BY create_time DESC </select>

<where>标签会自动处理第一个条件前的AND，可以避免SQL语法错误。LIKE的拼接用CONCAT而不是'%${realName}%'，因为后者存在SQL注入风险，用${}的方式在答辩时被老师看到是要扣分的。用#{param}是预处理占位符，安全且符合规范。

4.2 健康打卡Api接口与前端表单联动

前端使用简单HTML + JSP + AJAX组合就可以完成功能。为了让你看到实际效果，我把健康打卡的Controller层写一下：

@Controller @RequestMapping("/health") public class HealthCheckController { @Autowired private HealthCheckService healthCheckService; @ResponseBody @PostMapping("/submit") public Result submit(@RequestBody HealthCheck check, HttpSession session) { User loginUser = (User) session.getAttribute("loginUser"); if (loginUser == null) { return Result.error("请先登录"); } check.setUserId(loginUser.getId()); try { healthCheckService.submitHealthCheck(check); return Result.success("打卡成功"); } catch (BusinessException e) { return Result.error(e.getMessage()); } } }

前端如果是jQuery的AJAX，请求头需要设置Content-Type为application/json。如果不用@RequestBody接收JSON，也可以用传统的表单参数逐个接收，但字段多的时候还是用对象接收更整洁。另外一个容易出错的位置是日期类型在JSON和Java之间的转换，SpringMVC默认的Jackson需要配置日期格式化格式，常见的做法是加@JsonFormat(pattern = "yyyy-MM-dd", timezone = "GMT+8")注解。

4.3 预警功能与数据传输的实现方式

预警功能是系统里真正有"业务深度"的地方。触发预警的方式有两种：一是健康打卡时自动判定异常，比如体温超标或接触史为是；二是定时任务扫描，对连续多天未打卡的居民进行提醒。

对于第二种方式，SSM中启用Spring自带的@Scheduled定时任务即可。在Spring配置中开启任务注解支持：

<task:annotation-driven/>

然后写一个定时任务类，每天20:00扫描当天还没有打卡记录的居民，给他们的待办消息表插入一条"今日未打卡提醒"。这个功能要想显示在Web页面上，需要一张t_message（消息通知表），每次插入消息时同时写入接收人ID。用户登录后查询该表未读消息，完成一个轻量级站内消息系统。

这个设计借助定时任务，将"被动等待用户提交"变成"主动去发现异常"，是一个可以在答辩环节强调的能力点。而且它技术实现并不复杂，对Spring定时器的使用、对批量查询的SQL编写都有所覆盖。配合预警触发后的站内信通知，后端数据通过Controller返回JSON，前端通过AJAX刷新未读消息数，链路完整且高效。

5. 开发部署流程与实测运行记录

5.1 开发环境与工具清单

我实际跑通这套系统的环境如下，供你参考：

• JDK 1.8（SSM体系的稳定版本，不要盲目上JDK 17，兼容性问题会让你多花时间）
• Maven 3.6+（依赖管理和项目构建）
• MySQL 5.7或8.0（数据库存储，注意mysql-connector-java版本对应）
• Tomcat 8.5或9.0（Web服务器）
• IDEA（开发者工具，社区版就够用）
• Navicat或MySQL Workbench（数据库可视化操作）

Maven坐标里Spring版本建议5.x（5.2.x或5.3.x），MyBatis在3.5.x，MyBatis-Spring在2.0.x。不建议用太旧的Spring 4.x，因为新版本在性能和注解支持上明显更好，而且这个组合经过我反复测试非常稳定。

5.2 系统部署运行Checklist

开发完成后部署到Tomcat运行，按下面顺序检查基本不会出大问题：

1. 修改数据库配置文件中的URL、用户名、密码，确认MySQL本地服务已启动
2. 执行SQL脚本，建库建表，并插入一条初始管理员账号
3. Maven执行clean install打包，确认没有编译错误
4. 将war包放到Tomcat的webapps目录，启动Tomcat
5. 浏览器访问http://localhost:8080/epidemic/，正常跳转登录页
6. 用初始管理员账号登录，配置一个工作人员账号，然后分别从三个角色登录测试功能链路

下面这条核心业务链路建议完整走一遍再交：管理员创建居民账号 -> 居民登录完成健康打卡 -> 打卡时设置异常数据 -> 工作人员登录查看预警 -> 将居民标记为隔离 -> 居民登录查看自己的隔离状态 -> 居民申请物资 -> 工作人员处理物资配送。这条链路走通，系统核心功能就全部验证完毕了。

5.3 数据库连接与编译中高频报错解决速查

报错1：java.sql.SQLException: Access denied for user 'root'@'localhost'

标准排查流程：检查jdbc.properties里的用户名密码是否正确，注意properties文件里密码如果有特殊字符如!、#，需要做转义处理。MySQL 8.0默认的认证插件是caching_sha2_password，部分旧版本的mysql-connector-java不支持，解决方法是把连接驱动升级到8.0版本，或者在MySQL中执行ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '密码';换回旧版认证方式。

报错2：Invalid bound statement (not found): com.xxx.mapper.UserMapper.selectByCondition

这个报错几乎99%是因为MyBatis的Mapper接口和XML文件没有绑定成功。检查位置：Mapper接口在哪个包，XML就放在classpath下的相同目录；mapperLocations属性是否配置为classpath:mapper/*.xml；如果使用Maven默认结构，XML放在src/main/resources/mapper目录下就在classpath里，放在src/main/java下则需要额外在pom.xml中配置resources包含XML类型。

报错3：Error creating bean with name 'userMapper'或nested exception is org.apache.ibatis.binding.BindingException

通常是Mapper接口没有加@Mapper注解，或者组件扫描没有覆盖到它。SSM整合时，Spring扫描的包路径要能扫描到Service和Controller，而MyBatis的Mapper扫描需要单独配置<mybatis:scan base-package="com.community.epidemic.mapper"/>，这个是整合过程中最容易遗忘的一环。

报错4：前端页面CSS丢失或404

确认spring-mvc.xml中配置了<mvc:default-servlet-handler/>，同时参考web.xml中DispatcherServlet的url-pattern。如果设置为/，所有请求都进SpringMVC，静态资源必须由default-servlet-handler放行。如果设置为*.do，静态资源自然不受SpringMVC管理，但Controller方法映射路径也需要统一带.do后缀，风格简单但不够灵活。

注意：以上报错解决方式都是我在日常排错中验证过的通用方案。如果你遇到其他报错，先看控制台红色堆栈信息的前三行，一般是"找不到某类""绑定失败""空指针"这几种，用搜索引擎按"完整异常信息 + 框架名称"去搜，效率远高于自己猜。

6. 系统测试与验收注意事项

6.1 功能测试重点用例设计

毕业设计不需要完全按软件工程的标准写几十页测试用例，但重点功能至少要覆盖下面的核心场景：

这些用例每一个都对应当前章节讲解过的核心逻辑，建议在测试时用多账号多角色反复走几遍流程。特别是隔离到期自动解除的逻辑，我第一次测试时踩过端日期比较的坑——endDate存储当天日期时，用before(new Date())判断会提前一天解除隔离，后来改成!endDate.after(today)或endDate.compareTo(today) <= 0才正确。

6.2 系统演示准备与答辩加分项

系统开发完了，演示环节同样重要。在答辩或提交说明中，我建议准备一个"演示脚本"，配合核心业务链路一步步操作给老师看。重点展示几个有区分度的场景：管理员创建账号时的密码加密过程、居民打卡异常后工作人员收到预警并处理的过程、统计面板的图表联动。这些功能点如果你能现场画一下表关系或者讲清楚触发时机，老师对系统完整度的认可会高很多。

答辨时老师最常问的问题不外乎这几类：为什么选这个课题、系统有哪些角色与权限控制、数据库如何设计的、遇到的最大问题是什么。前三个问题你在本篇文章的框架内准备足够扎实；最后一个问题，我建议准备一个真实的开发细节，比如你测出隔离状态自动更新的边界时间bug，然后讲你是怎么通过调整日期比较逻辑解决的。这类真实的排错经历最有说服力。

7. 项目验收后的扩展思路

系统交完不代表项目的生命力就结束了。基于SSM的社区疫情管理系统，做完之后其实还可以做几个方向的升级扩展，给项目加分也给自己增加可讲的故事。

第一个方向是引入Redis缓存热点数据。比如健康打卡每日首次提交会触发多条SQL执行，如果把这些热点数据缓存起来，可以大幅降低数据库压力。引入Redis在SSM里只需要添加依赖、配置连接、然后在Service层注解或代码里做缓存读写。这就能让你的技术栈从"经典SSM"升级到"SSM + Redis"，答辩时就有"高并发优化"层面的内容。

第二个方向是人脸识别或无感测温的接口预留。当然毕业设计阶段不用真正对接硬件，但可以在系统里设计一个第三方接口调用的抽象层，比如一个HealthDeviceService接口，写一个模拟实现类，模拟从测温设备同步体温数据。这个设计展现了面向接口编程的思想，答辩讲起来也会比较有亮点。

第三个方向是数据导出功能。社区工作人员经常需要上报表格，给统计查询增加一个"导出Excel"按钮，后端使用EasyExcel或POI生成文件，前端触发下载。这个功能工作量不大但实用性很高，在很多评审眼里，这类"从用户实际工作流出发的功能"比一些花哨的界面更有价值。

第四个方向是移动端适配或小程序端。虽然毕业设计通常不需要真的做小程序，但你可以在系统需求说明里论证"移动端轻量化访问"的必要性，前端使用响应式布局让页面在手机上可正常浏览，这是成本可控且体验提升明显的一件事。

8. 写在最后的一点心得体会

这套系统我从选型到完整实现，最深的体会是：技术框架只是手段，真正让项目立住的，是对业务场景的完整理解和数据流的清晰设计。SSM这套老组合虽然不花哨，但它能让你把请求怎么进来、SQL怎么执行、事务什么时候提交这些基本功看得清清楚楚。

如果你正在为毕业设计发愁，我的建议是不要急着写代码，先把用户的典型操作流程写在纸上，把数据库表结构画出来，把每个角色能做什么、不能做什么列清楚。想明白了这些，开发只是时间问题，而不是能力问题。

最后再分享一个小技巧：开发过程中始终保持一个"数据追踪"的习惯——每次写完一个功能，就用数据库客户端查一下对应表和关联表的数据，看是否和预期一致。这种"写完就查"的笨办法，能帮你把大部分隐性bug消灭在萌芽阶段，远好过最后集中测试时面对一堆互相牵连的问题无从下手。希望这篇基于SSM的社区疫情管理系统的实现记录能帮你少走几步弯路，顺利把项目做完做好。