SpringBoot社区防疫信息管理平台：从需求到监控的完整实现

开头想先讲个场景：很多小区的健康数据采集，实际还是靠物业人员拿着Excel表格挨家挨户统计，居民在微信群里接龙体温报备，物业再把零散信息一条条粘到表格里。这套流程不是不能用，但漏报、错报、重复统计几乎不可避免，每天光校对数据就要花掉大半时间。所以当我看到这个题目——“基于SpringBoot的社区防疫信息管理平台，智慧物业疫情数据上报与监控系统”——第一反应是：这是个既贴近真实业务，又能把基本功完整展示一遍的毕设选题。

本文就把我从需求梳理、技术选型、数据库设计到核心代码实现的完整思路拆开讲，重点回答三个问题：这个项目到底在做什么、为什么用SpringBoot这套组合、以及哪些细节决定了它能不能在答辩时站稳脚跟。如果你是正在选毕设方向的计算机相关专业学生，或者想快速搭一套物业信息采集类管理系统的开发者，这篇内容可以直接作为参考骨架。

1. 为什么这个选题值得做：它不是“疫情系统”，而是完整的管理信息系统

1.1 同一个标题，其实是三层能力

很多人第一眼看到“疫情防控物业信息采集系统”会觉得题目太小，或者相反，觉得涉及疫情就很复杂。真正把标题拆开看，它其实是由三个子系统拼成的综合体：

• 物业信息采集系统：解决“数据怎么进来”。核心是住户信息管理、楼栋房间绑定、健康数据填报、批量导入。说白了，这是整个平台的数据入口。
• 社区防疫信息管理平台：解决“数据怎么被使用”。物业、社区、居民三类角色分别看到不同的工作台，管理上报记录、处理异常、发布公告。这是业务核心。
• 智慧物业疫情数据上报与监控系统：解决“数据怎么变成决策”。通过定时统计、异常预警、趋势图表，让管理人员一眼看到哪个楼栋上报率低、哪类异常在增加。

这三层关系可以理解为一条流水线：采集是原料入口，管理是加工处理，监控是质量检测。只做其中任何一层都能运行，但把三层打通才是这个题目的真正价值。毕业设计评分时，老师看重的往往就是这种“完整业务链路”的体现。

1.2 为什么“管理信息系统”这个分类比“疫情系统”更准确

我见过不少同学一听“防疫”就想去搞大数据分析、健康预测模型，最后把毕设做成一个四不像。不是说技术不能炫，而是脱离业务场景的技术堆砌，在答辩时最容易被打穿。

这个题目的本质是典型的管理信息系统（MIS），它考察的核心能力包括：

• 数据库设计是否合理，能否支撑每日上报、统计、追溯；
• 权限控制是否够用，居民、物业、社区三种级别的数据隔离是否严密；
• 业务流程是否闭环，从上报、审核、预警到处置是否有状态流转；
• 工程化是否规范，接口风格、日志记录、异常处理是否像真实项目。

这些恰恰是软件工程专业最基础、也最被看重的部分。用疫情信息采集作为业务载体，只是给这套能力找了一个真实的应用场景，而不是把它变成数据科学项目。

1.3 选这个题对普通学生的友好程度

说实话，这套系统即便是一个只学过Java Web基础的学生，也完全啃得下来。需要的技术栈很标准：SpringBoot做后端、MyBatis-Plus操作数据库、MySQL存数据、Vue或Thymeleaf做前端、Spring Security或Shiro管权限。如果还想加亮点，再引入Redis做缓存、定时任务做每日统计、EasyExcel做导出，性价比非常高。

对比满大街的“网上商城系统”和“校园论坛系统”，这个题目还有一个隐藏优势：业务规则非常明确，不容易做到一半发现需求模糊。比如“上报时体温大于37.3度要预警”“超过48小时未上报要提醒”“物业只能查看自己小区的数据”，这些都是可以直接落地的规则，写代码时几乎不用纠结。

2. 需求分析这一步做到位，后面写代码等于在抄自己的笔记

2.1 四类角色和他们各自关心的数据

我习惯在写任何代码之前，先列一张角色-功能矩阵。这个项目里至少有四类角色，很多同学只做居民和管理员两类，那是远远不够的：

这四类角色的权限边界必须从一开始就定死。特别是物业人员只能看到自己负责小区的数据，社区管理员可以看到辖区所有小区的汇总数据，居民只能看到自己的数据，这条规则直接决定了数据权限模块怎么设计，后面会单独讲。

2.2 两条核心业务流，先画清楚再动工

第一条是“日常采集流”：

居民登录平台或小程序 → 填写今日健康状况（体温、症状、行程） → 系统校验数据合法性 → 写入健康上报记录表 → 物业人员在工作台查看本小区上报情况 → 到期未上报的自动生成提醒 → 社区管理员查看整体上报率统计

第二条是“异常处置流”：

系统根据规则引擎判断上报数据异常（如体温≥37.3℃或勾选高风险症状） → 自动生成异常预警记录 → 推送给对应物业人员 → 物业电话核实后登记处置结果 → 如需社区介入则上报流转 → 社区管理员复核后关闭该条预警

这两条流必须串起来。我在项目里遇到的第一个坑就是只做了上报功能，没有做预警，“采集”和“监控”完全割裂，后来硬是把预警流程补上，整个系统才算真正立住。建议你在需求文档里把这两条流画成泳道图，哪怕只是手绘PPT级别的，答辩时展示出来效果也会好很多。

2.3 容易被漏掉，但加分明显的隐性需求

经验告诉我，评审老师不太关心你写了多少行代码，但特别容易因为几个细节给高分：

• 批量导入：物业手里通常有现成的住户Excel表，支持批量导入比一条条手工录入有价值得多；
• 时间维度统计：按日、按周、按月统计上报率和异常率，用折线图和柱状图呈现；
• 导出功能：健康上报明细、异常处置记录都要能导出Excel，这是物业真实的行政需求；
• 操作日志：谁在什么时间改了什么数据，必须留痕，这是管理系统的合规底线；
• 数据字典：症状、风险等级、处置状态这类枚举值不要写死在代码里，用字典表维护。
• 消息提醒：不上报自动提醒、异常预警通知，如果不想对接短信，站内消息就够了，但必须要做，这是保证“闭环体验”的关键环。

这些功能单个来看工作量不大，但能把系统从“一个简单的CRUD项目”提升到“像一个真正能被社区使用的平台”。

3. 技术选型：为什么SpringBoot+MyBatis-Plus+MySQL是这支队伍的最佳配置

3.1 不搞微服务，不是保守，是合理取舍

每次有人问我“能不能用SpringCloud做这个毕设”，我都会反问一句：你准备拆几个服务？拿这个项目来说，核心其实只有一个后端工程，强行拆成用户服务、上报服务、统计服务，带来的分布式事务、服务间调用、链路追踪问题，哪一个都比业务本身更难处理。单体应用在这个体量下不是缺点，而是优点。

SpringBoot在这类项目里的地位不用多说。它内置Tomcat、自动配置、生态成熟，几乎不需要额外配置就能把Web项目跑起来。MyBatis-Plus则是对MyBatis的增强，内置了BaseMapper和IService，单表CRUD基本不用写SQL，把精力节省出来留给真正复杂的分组统计和关联查询，对学生来说非常友好。

3.2 前后端分离到底分还是不分

我倾向于推荐Vue + Element UI 做前端，SpringBoot 提供JSON接口这种前后端分离方案。理由有三个：

1. 毕业设计通常要求展示系统，页面好不好看直接影响第一印象；
2. 前后端分离更贴近企业真实开发模式，答辩时可以说“前端独立部署、后端只负责API”；
3. 这个项目本身权限多、表单多、表格多，Vue的数据绑定和组件化处理这类页面比模板引擎顺滑太多。

当然，如果时间实在紧张，用Thymeleaf在服务端渲染页面也能完成，只是后面想加复杂交互时会比较痛苦。我自己的经验是：只要能熟练使用Vue的基础语法——数据绑定、v-for、v-model、axios请求，就不需要担心前端拖后腿。

3.3 其他组件的选型逻辑与最终清单

跑通一个基础版本不需要太复杂，但为了体现系统成熟度，我建议加这几个轻量组件：

这里说一个很容易踩的坑：千万不要为了简历好看，硬上自己不熟的技术。我们学校就有同学在项目里加了RabbitMQ，结果答辩时老师问“为什么需要消息队列”，他答不出业务场景，反而扣分。技术应该服务于业务，而不是反过来。

4. 数据库设计：把“健康上报”做成流水账，而不是随时改写的状态

4.1 表的设计先想清楚实体关系

这个系统的实体不算多，我最终落地的核心表如下：

• sys_user：登录账号表，包含用户名、密码、手机号、角色ID、所属小区ID、状态；
• sys_role / sys_menu / sys_role_menu：RBAC权限三件套，后端通过角色控制菜单和接口访问；
• community_info：小区信息表，包括小区名称、地址、可容纳户数、所属区域编号；
• building_info：楼栋单元房号表，设计成一条记录代表一个具体的“楼栋-单元-房号”，方便住户绑定；
• resident_info：住户信息表，关联用户表，存储姓名、身份证号、现居住人数、入住状态、与户主关系；
• health_report：健康上报记录表，这是整个系统的数据核心，后面重点展开；
• abnormal_record：异常预警记录表，保存异常类型、触发规则、处置状态、处置人、处置结果；
• notice_info：公告表，区分社区公告和物业公告，后台发布到小程序或Web端展示。
• operation_log：操作日志表，AOP切面写入关键操作。

一张核心的原则是：用户表管“账号”，住户表管“人”，楼栋房号表管“位置”，上报记录表管“行为”。账号和住户解耦的好处是，同一套物业系统既支持住户本人登录，也支持物业代录，灵活性高很多。

4.2 健康上报记录表为什么要设计成流水表

这是我认为整个数据库设计里最关键的一处。很多同学会设计成“住户健康状态表”，即一个住户一行记录，体温异常就UPDATE字段。这个设计的问题在于：状态被覆盖后，历史记录就丢了，你是没法回答“这个人上周五到底上报了什么”的。

正确的做法是设计成流水表，每次上报都插入一条新记录，不做UPDATE，只允许管理员做“修正”操作（修正本身就是插入一条带有修正标记的新记录）：

CREATE TABLE health_report ( id BIGINT AUTO_INCREMENT PRIMARY KEY, resident_id BIGINT NOT NULL COMMENT '住户ID', report_date DATE NOT NULL COMMENT '上报日期', body_temperature DECIMAL(4,1) NOT NULL COMMENT '体温，如36.5', symptoms VARCHAR(255) COMMENT '症状标签，多个用逗号分隔', has_contact_risk TINYINT NOT NULL DEFAULT 0 COMMENT '是否接触风险人员 0否 1是', location_status VARCHAR(50) COMMENT '所在地状态：在本地/外地', remark VARCHAR(500) COMMENT '备注', report_type TINYINT NOT NULL DEFAULT 1 COMMENT '1正常上报 2修正记录', report_source TINYINT DEFAULT 1 COMMENT '1居民自报 2物业代录', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted TINYINT NOT NULL DEFAULT 0 COMMENT '逻辑删除', KEY idx_resident_date (resident_id, report_date), KEY idx_report_date (report_date) ) COMMENT='健康上报流水记录';

看这张表，有一条非常重要：上报日期是业务日期，创建时间是实际操作时间。正常逻辑下，居民在当天23:59前上报就算当日上报；但有的居民会漏报，第二天补报昨天的数据，这时业务日期就是昨天，创建时间是今天。如果不加report_date，只按create_time统计，补报数据就会错位到第二天，上报率统计就全错了，这个细节是实际跑过数据之后才发现的。

4.3 索引和统计SQL的优化思路

每日统计“某小区上报率”是一个非常高频的操作，SQL大概是：

SELECT b.community_id, COUNT(DISTINCT r.id) AS total_residents, COUNT(DISTINCT hr.resident_id) AS reported_count FROM resident_info r LEFT JOIN building_info b ON r.building_id = b.id LEFT JOIN health_report hr ON hr.resident_id = r.id AND hr.report_date = #{today} AND hr.deleted = 0 WHERE r.deleted = 0 AND r.status = 1 GROUP BY b.community_id;

这种SQL在数据量小的时候看不出来问题，但如果小区有几千户，天天count全表，性能就会下降。我的改进方案是两招：

• 给health_report.report_date建索引，让每日范围查询走索引；
• 跑一个每日上报汇总定时任务，在凌晨把昨天的上报率汇总结果提前算好放进一张report_daily_summary表，页面展示时直接查汇总表，只有明细查询才走原始表。

及时统计和定时预计算，是管理信息系统里最常用的性能思路。答辩被问“系统并发高怎么办”时，这套回答比空谈优化有用得多。

5. 核心模块实现：从“会上报”到“能预警”的四个关键功能

5.1 统一返回与全局异常：项目管理感的起点

很多同学写的Controller返回结果一会儿是Map，一会儿是字符串，前端对接时非常痛苦。项目一开始就应该定义统一返回结构，我习惯叫Result<T>，包含code、message、data三个字段。

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "success"; result.data = data; return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.code = code; result.message = message; return result; } }

配合@RestControllerAdvice定义的全局异常处理器，把参数校验异常、业务异常、兜底异常分门别类地返回给前端。这块虽然代码量不大，但它在评分标准里对应的就是“工程规范”那一项，非常值得做扎实。

5.2 健康上报接口：一次点击背后的完整校验链路

健康上报是所有模块里最核心的接口。前端提交体温、症状、接触史这些信息，后端要做的事远不只是插入一行数据：

@PostMapping("/report") public Result<Void> submit(@RequestBody @Valid HealthReportDTO dto) { // 1. 获取当前登录用户，找到对应的住户 Long residentId = residentService.getByUserId(getCurrentUserId()); // 2. 校验当天是否已经上报过（允许修正，但需要标记） Long todayCount = healthReportService.lambdaQuery() .eq(HealthReport::getResidentId, residentId) .eq(HealthReport::getReportDate, LocalDate.now()) .eq(HealthReport::getReportType, 1) .count(); if (todayCount > 0 && dto.getReportType() == null) { throw new BizException("今日已上报，如需修改请发起修正申请"); } // 3. 检查体温范围 if (dto.getBodyTemperature() != null && (dto.getBodyTemperature().compareTo(new BigDecimal("34")) < 0 || dto.getBodyTemperature().compareTo(new BigDecimal("42")) > 0)) { throw new BizException("体温数据不合理，请重新测量"); } // 4. 落入上报表 healthReportService.save(buildEntity(dto, residentId)); // 5. 触发规则引擎 warnService.evaluate(dto, residentId); return Result.success(null); }

这里每一步都有意义。第2步防重复上报，第3步是基础的数据合法性校验，第5步把“上报”和“预警”解耦——上报只负责记录事实，预警由专门的规则引擎负责，这样以后新增预警规则时，不需要改动上报接口。

5.3 预警规则引擎：把“体温超过37.3度”变成可配置规则

预警是“监控系统”这个定位落地的关键。我的做法是在WarnService里维护一个规则链，每条规则都是独立的判断逻辑，代码看起来很清楚：

@Component public class WarnService { private static final BigDecimal TEMP_THRESHOLD = new BigDecimal("37.3"); private static final String HIGH_RISK_SYMPTOMS = "发烧,干咳,乏力,呼吸困难"; @Autowired private AbnormalRecordMapper abnormalRecordMapper; @Transactional public void evaluate(HealthReportDTO dto, Long residentId) { boolean abnormal = false; String warnType = ""; if (dto.getBodyTemperature().compareTo(TEMP_THRESHOLD) >= 0) { abnormal = true; warnType = "体温异常"; } String[] symptomArr = HIGH_RISK_SYMPTOMS.split(","); for (String s : symptomArr) { if (dto.getSymptoms() != null && dto.getSymptoms().contains(s)) { abnormal = true; warnType = "症状异常"; break; } } if (dto.getHasContactRisk() != null && dto.getHasContactRisk() == 1) { abnormal = true; warnType = "风险接触"; } if (abnormal) { AbnormalRecord record = new AbnormalRecord(); record.setResidentId(residentId); record.setWarnType(warnType); record.setDetail(JSON.toJSONString(dto)); record.setStatus(0); // 0待处理 1已核实 2已闭环 abnormalRecordMapper.insert(record); } } }

这里的关键点是把异常明细用JSON存起来。因为上报字段后续可能会变化，硬编码成一个字段一个字段去保存，以后加一个字段就要改表结构。存JSON虽然查询不方便，但能从“已存档”的角度保证数据完整性，实际项目中保存快照是非常常见的做法。

5.4 监控统计与物业工作台

监控端的核心是给前端ECharts提供数据接口。我做一个StatisticsController，提供三个核心图表：

• 上报率趋势图：按日期返回已上报人数/应上报人数；
• 异常类型分布图：按预警类型分组统计数量；
• 小区上报率排名图：跨小区对比。

后端实现时用Stream分组或者SQL分组都行，重点是一个接口对应一个DTO，别为了省事返回一个Map了事。物业工作台则是把待审核列表、异常预警列表、未上报住户提醒聚合到首页，让物业人员一打开系统就知道今天要做什么。这是“智慧物业”体验的最直观体现。

6. 权限、安全与答辩准备：让系统看起来像“能上线的产品”

6.1 登录权限好做，数据权限才是分水岭

Spring Security负责登录和角色授权并不难，真正考验设计能力的是数据权限。什么叫数据权限？就是“物业经理李姐只能看到春风小区的数据，不能看到对面阳光小区的数据”，而社区管理员又必须看到两个小区的数据。

我的实现思路是在building_info表上挂一个community_id，住户表通过building_id关联到小区。物业用户表也有community_id字段。后端每次查询住户或上报记录前，先去当前登录用户上下文里取community_id，然后强制拼进查询条件：

@TableField(fill = FieldFill.INSERT) private Long communityId;

再配合MyBatis-Plus的拦截器做数据权限自动注入，对所有涉及住户的Mapper查询统一加上“当前用户只能查自己小区”的SQL片段。这样即使前端被人绕过，直接调接口，也拿不到其他小区的数据。只在前端组件里写v-if="role==='property'"隐藏按钮是毫无安全意义的，这条一定要记住。

6.2 敏感数据脱敏、密码加密、操作日志

这个项目的用户数据包含姓名、身份证号、手机号，都算敏感数据，答辩时老师几乎必问“系统怎么保证用户隐私”。我的做法是：

• 密码字段用BCrypt哈希，数据库里永远不存明文；
• 手机号和身份证号在前端展示时脱敏：138****1234、110***********001X；
• 管理端的查看明细接口必须记录操作日志，通过AOP切面统一记录操作人、操作时间、操作接口、请求参数（身份证号等敏感字段打码后再写日志）；

这些都不是花哨技术，但体现了数据安全意识。真实业务里这些是硬性合规要求，放毕设里就是明显的加分项。

6.3 演示环境搭建与答辩踩坑提醒

最后这点非常经验主义：代码写得再好，演示时跑不起来就是零分。我自己的做法是写一个docker-compose.yml，把MySQL、Redis、后端服务一键启动，数据库初始化脚本用Flyway管理，第一次启动自动建表并插入五组演示数据——两个小区、三名物业、五十户住户、两周的健康上报流水。

答辩演示前必须模拟一遍所有流程：从居民登录、上报、触发预警，到物业处理预警、社区查看统计，全程不要卡壳。这里分享一个我们系的真实情况：一位同学答辩时前端连不上后端，查了半天发现是端口没放开；另一位同学被老师要求现场查看数据库，结果因为没用navicat或类似工具，数据库操作不熟练愣了几秒。这些小问题在评分时比你想的影响大得多。

另外预判一下老师大概率会问的问题，不要被问住：

• “为什么体温阈值要写死在常量里，不放到配置中心？”（可回答：毕设体量用常量足够，真实项目会放Nacos或数据库字典）；
• “一个人在一套房里上报了，但实际住了一家人，怎么处理？”（可回答：住户信息里增加居住人数，上报时支持按户代报）；
• “如果5000个用户同时上报，系统扛得住吗？”（可回答：引入Redis缓存热点数据，上报接口幂等设计，必要时用MQ异步落库）；
• “逻辑删除和物理删除怎么选？”（可回答：业务数据一律逻辑删除，定时任务清理1年以上的归档数据）；
• “你这个系统的报表能支持钻取吗？”（可回答：目前支持汇总到明细的跳转查询，更深层次的钻取需要BI工具支撑）。

这些问题的核心不在于答案多么完美，而是让老师看到你是真的做过思考和权衡的。

最后的实操心得

回头复盘这个项目，最大的体会是：管理信息系统的技术门槛真的不高，难的是把业务逻辑想得足够细。SpringBoot、Vue、MySQL这些工具只是手段，真正拉开差距的地方在于——你有没有设计出合理的状态流转，有没有想到数据权限和操作日志，有没有把一个看似简单的“上报”做成可追溯、可预警、可统计的完整链路。如果时间允许，建议在这个基础上把小程序端再加上去，让居民不用装App、直接在微信里完成上报，整个系统的应用价值会再上一个台阶。这个项目的扩展空间其实很大，物业报修、访客登记、车辆管理都可以复用同一套用户和权限底座，做一次毕设相当于搭了一套小区数字化管理的地基。