飞翔的十号如果你正准备做一个“Java + SpringBoot + JavaWeb”方向的物业疫情防控信息采集系统毕设，我的第一句建议是：先别急着写登录。这种题目看起来是典型的管理系统，数据库里放几张表、页面上做几个增删改查就能交差，但你真去物业蹲半天就会发现，信息采集系统的难点根本不在“查”，而在“采集回来的信息有没有形成闭环”：今天谁没上报、上报异常的人有没有被跟进、进来的人到底离没离开、重点观察对象哪天到期。SpringBoot 和 JavaWeb 只是把流程落地的工具，业务链路的完整度才是答辩时真正能拉开差距的地方。
这篇文章我按自己做这套系统的顺序展开，从需求模型、技术选型、数据库设计、后端接口、前端咬合到最终部署演示，适合准备用这个题目做毕业设计、又不想把项目做成普通 CRUD 的同学参考。文章里有完整表结构、核心代码和一批只有真正跑过一遍才会发现的坑，基本属于可以直接照着抄作业的版本。
1. 这个系统的题眼不是“CRUD”，而是采集闭环
1.1 物业一天的工作流程，就是需求文档
很多同学拿到“物业疫情防控信息采集系统”这个题目后，第一反应是拆成：小区管理、楼栋管理、住户管理、健康上报、访客登记、公告管理，然后开始设计菜单。这么拆本身没错，但容易做成一堆互相不关联的独立页面。
我建议你换个角度，把物业一天的工作流程写出来：
- 早上物业管理员打开系统，看一下今天的健康上报完成率，找出还没有上报的住户，逐个打电话询问原因。
- 门岗值班员站在小区出入口，遇到访客要登记姓名、电话、访问的楼栋房号、测体温，然后再放行。访客离开时还要销掉记录，不然人进去了到底走没走，谁也说不清。
- 有一个住户昨天上报了体温异常，物业人员需要打电话回访，问他现在体温多少、有什么症状，把这个跟进过程记录下来。
- 某位住户到了健康观察期的最后一天，系统应该自动提示，而不是让物业翻纸质台账去数日子。
如果你把这一条流程落到系统里，就会发现纯粹的管理系统根本不够用。你至少需要三样东西：一张“每日上报”表来记录住户的健康状态；一张“回访跟进”表来记录异常状态的处理过程；一组定时任务来处理未上报提醒和观察到期自动解除。
这套逻辑才是疫情信息采集系统的核心。物业每天采集到的不是“数据”，而是需要处置的事件。一个体温异常的条目没人跟进，过两天就会被新的数据冲掉，系统就失去了意义。
1.2 角色权限的最小闭环设计
做这类系统另一个容易翻车的点，是权限设计。你可以做得非常轻，但不能没有角色边界。我在设计时把角色拆成四类：
| 角色 | 核心诉求 | 开放权限 |
|---|---|---|
| 物业管理员 | 看全局、管档案、处理异常 | 住户档案、健康上报、重点人群、出入登记、统计报表 |
| 门岗值班员 | 快速登记、快速查询 | 出入登记、住户联系电话查询、来访记录查询 |
| 公司/社区查看账号 | 只看数据不操作 | 统计汇总、各小区完成率 |
| 住户（可扩展） | 自己填报、看通知 | 仅限本人和本房屋数据 |
我的建议是不要在这种规模的项目里引入完整的 RBAC 五表模型（用户表、角色表、菜单表、用户角色表、角色菜单表），对毕设来说太重。你只需要在 sys_user 表里加一个 role_code 字段，配合后端拦截器，在接口层做粗粒度控制就足够了。
但这不意味着你可以完全不管权限。比如门岗值班员按理不应该有修改住户档案的权限，如果你不做任何限制，他只是不知道入口，直接输入 URL 依然能访问后台接口，演示的时候被老师点到这个问题会很尴尬。所以至少要有一个拦截器，按请求路径前缀做一次校验，再配合前端按用户角色渲染菜单，基本就能覆盖需求。
1.3 别把“每日上报”做成一次性录入
还有一点，设计上报功能时要区分“住户本人上报”和“物业代录”两类场景。毕设阶段大多数同学只做了物业端，由管理员帮住户录入当天的体温和健康状态，这也能跑通。但有一个细节容易被忽略：一个人今天已经上报过了，你再给他录一次，应该明确提示而不是直接覆盖。
更合理的方式是，后端把“当天是否已上报”作为一个业务校验条件：如果还没有记录，就插入；如果已经有了，就提示“今日已上报，如需更正请走修改流程”，同时要在数据库层面加唯一索引兜底。前端按钮禁用只是暂时的，真正防止重复数据靠的是后端的校验逻辑和数据库的唯一约束。这条经验在很多毕设答辩里都会被问到。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. SpringBoot 版本和工程分层：哪些坑值得提前避
2.1 JavaWeb 不等于 JSP，更不等于老古董
毕设题目里同时出现“JavaWeb”和“SpringBoot”，有些同学会纠结：是不是必须要用 JSP？其实没有必要。
JavaWeb 指的是基于 Java 技术构建 Web 应用这套体系，Servlet 是它的底层标准。SpringBoot 内部仍然是基于 Servlet 体系跑的，只是在 Tomcat 基础上做了自动配置。你用 SpringBoot 写出的接口，本质依然是 JavaWeb 应用。如果答辩老师问“Servlet 在哪里”，你可以回答：SpringBoot 的核心入口是 Spring MVC 的 DispatcherServlet，所有请求都会经过这个前端控制器再分发到 Controller。
界面层你可以选三种方式：
- 用 Thymeleaf 服务端渲染，适合页面不多、每个页面都要拼接数据的场景。
- 用 JSP，需要额外配置视图解析器、war 打包和 JSP 编译依赖，成本偏高。
- 用纯静态 HTML + Ajax 请求后端 JSON 接口，开发和维护最直观。
如果没被老师强制要求用 JSP，我建议选第三种。前端就是普通的 HTML、CSS、JavaScript，后端只负责提供 JSON，两者通过接口沟通。这样前端不用依赖后端模板语法，逻辑也更清楚。SpringBoot 默认会把 src/main/resources/static 目录下的静态资源映射到根路径，页面直接访问即可。
2.2 环境版本推荐：停在 SpringBoot 2.7 不是保守
这几年网上很多资料在推 SpringBoot 3.x，因为新版本确实更好用。但如果你是在做毕设而不是生产级项目，我建议老老实实用 SpringBoot 2.7.x，特别是 2.7.18。原因有三个：
第一，SpringBoot 3.x 强制要求 JDK 17，而很多同学的电脑上装的是 JDK 8 或 11，重新配置环境要花时间。第二，网上大量现存教程、博客、代码片段都基于 SpringBoot 2.x，你搜索问题时能直接找到答案。第三，MyBatis-Plus、连接池、代码生成器等常用组件对 SpringBoot 2.x 的兼容性更稳定，不需要为了版本冲突去翻各种 release note。
配套的版本组合我也给你一个参考：
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| JDK | 8 或 11 | 8 最稳，11 也可以 |
| SpringBoot | 2.7.18 | 2.x 最后一个版本 |
| MyBatis-Plus | 3.5.3.1 | 常规 CRUD 和分页足够 |
| MySQL | 8.0 | 用 5.7 也行，注意驱动名称差异 |
| Maven | 3.6+ | 不要用太老的版本 |
MySQL 8 连接驱动要写 com.mysql.cj.jdbc.Driver，并且连接串里加上 serverTimezone=Asia/Shanghai，否则容易出现时区问题，数据库时间和 Java 时间差八个小时。
2.3 工程目录：让别人一眼看出你会分层
工程结构虽然不是功能，但直接影响老师对你代码的第一印象。很多同学喜欢把 Controller、Service、Dao 堆在三个包下，业务逻辑全写在 Controller 里，一个方法几百行，看起来也能跑，但是答辩时被问“这段代码为什么放在这里”很容易卡住。
我推荐的包结构是这样的：
text复制src/main/java/com/example/epms
├── EpmsApplication.java
├── common
│ ├── config # 拦截器、跨域、MyBatis-Plus 分页配置
│ ├── result # 统一返回对象 Result
│ └── exception # 统一异常类和全局异常处理器
├── controller
│ ├── admin # 物业管理后台相关接口
│ └── web # 门岗操作、健康上报等业务接口
├── service
│ ├── HealthReportService.java
│ └── impl
├── mapper
├── entity # 数据库实体对象
├── dto # 接收前端参数的载体
├── vo # 返回给前端的视图模型
└── task # 定时任务
Controller 层只做参数接收和简单校验，然后把请求转给 Service；Service 层处理业务规则、事务和状态流转；Mapper 层只负责数据库访问。为什么要这么做？一个很直接的例子：健康上报功能可能同时在 PC 端后台、门岗自助终端和住户手机端被调用。如果你把“检查今日是否已经上报、体温是否超阈值、是否需要生成跟进记录”这套逻辑写在 Controller 里，三个入口就要写三遍，后面规则一变，改的地方也分散。放到 Service 里只需要维护一份逻辑。
3. 数据模型先行：几张核心表怎么设计才能承载闭环
3.1 六张核心表的关系
数据库设计我觉得是这套系统里最值得花时间的一步。表结构建好了，后面编码就是按部就班的事；表结构建得不对，写一半发现要联的表对不上，再回头改就得牵连前后端一起动，非常痛苦。
我用到的核心表大概六张：
| 表名 | 作用 | 关键关联 |
|---|---|---|
| bg_community | 小区 | 最顶层组织 |
| bg_building / bg_house | 楼栋 / 房屋 | 小区下挂楼栋，楼栋下挂房屋 |
| bg_resident | 住户档案 | 关联房屋 |
| bg_health_report | 每日健康上报 | 关联住户 |
| bg_access_record | 出入 / 访客登记 | 关联住户或直接冗余访客信息 |
| bg_follow_record | 回访跟进记录 | 关联上报记录或住户 |
另外我会加一张 sys_user 来存物业内部账号，用 role_code 区分角色。住户和 sys_user 先不强行绑定，因为毕设阶段住户一般由物业代录，如果有住户自助登录，再让 user 表里的 resident_id 指向住户档案。
这里有个设计上的建议：表之间不要加物理外键约束，只保留逻辑外键和索引。比如说 bg_health_report.resident_id 逻辑上关联 bg_resident.id，但在建表时不写 FOREIGN KEY。原因是在演示和开发阶段经常要批量造数或者手动删除调试数据，物理外键会让操作顺序变得特别麻烦，经常报“外键约束失败”。逻辑外键加上索引，既保证查询效率，又保留灵活性。
3.2 住户、健康上报、出入登记表的 SQL 示例
下面给你三段可以直接用的建表 SQL，分别是住户档案、每日健康上报和出入登记。字段命名我统一用下划线，和 Java 实体的驼