1. 疾控业务为什么需要一套独立系统——从表格台账到信息化的真实痛点
先聊个很多人忽略的背景。疾控中心、社区卫生服务中心、医院防保科这些机构，过去很长一段时间里做传染病报告、疫苗接种登记、重点人群随访，靠的是Excel台账加纸质档案。数据分散在经办人手里，统计报表靠人工汇总，跨科室调数据要打电话催。疫情来的时候，所有问题瞬间放大：密接转运记录对不上、疫苗接种批次追溯困难、上报数据延误。
我做过几个医疗信息化的项目，后来接触了这套基于Java SpringBoot+Vue3+MyBatis+MySQL的疾病防控综合系统，最大的感受是——这类系统的核心价值根本不在"功能多炫"，而在于把疾控业务里的数据流理顺。传染病报告从发现、登记、审核到上报，疫苗接种从库存、接种、留观到异常反应追踪，重点人群从建档、随访到干预效果评价，每一步都需要留痕、可查、可统计。
这套系统解决的就是这个层面的问题：前后端分离架构，后端统一提供RESTful API，前端Vue3单页应用负责操作界面，MySQL存业务数据，MyBatis负责数据库访问。对于高校毕业设计、中小型医院防保科信息化改造、疾控相关课题研究，甚至个人接外包项目，这个技术组合都非常典型、够用、好维护。
适合谁来参考？如果你是做Java后端开发想补一个完整全栈项目，或者刚学完SpringBoot和Vue3想找一个业务逻辑不算复杂但五脏俱全的练手项目，又或者你正需要一套能跑通"传染病报告+疫苗接种+重点人群管理"流程的疾控系统原型，这篇内容都值得你从数据库设计一路看到部署踩坑。
下面我把这套系统的设计思路、实现链路和真实开发中容易翻车的地方拆开讲，尽量讲透。
2. 技术选型不是跟风——这套组合到底解决了疾控系统的哪些问题
很多初学者一上来就问"为什么用SpringBoot不用SSH""为什么用MyBatis不用JPA""为什么前端用Vue3不用React"。这些问题如果脱离业务场景去回答，基本都是在背八股。我把这套选型的理由结合疾控系统的特点重新捋一遍。
2.1 SpringBoot：把繁琐配置砍掉，让开发重心回到业务逻辑
疾控系统的后端逻辑并不复杂，主要是增删改查加统计报表。如果用传统SSH框架，光配置文件就够你折腾一两天。SpringBoot的核心优势是自动配置和起步依赖，比如你引入spring-boot-starter-web，内嵌Tomcat、默认的MVC配置、Jackson序列化全部就位，几乎零配置就能跑起一个Web服务。
这里有个容易被忽略的点：SpringBoot版本选型。现在SpringBoot 3.x要求JDK 17以上，如果你本机还是JDK 8，硬上3.x版本会遇到一堆依赖兼容问题。我建议做这类疾控系统用SpringBoot 2.7.x，稳定、资料多、和MyBatis、PageHelper这些老牌组件的兼容性最好。这是很多人踩过的坑，后面部署部分我会再提。
2.2 MyBatis而不是MyBatis-Plus：可控的SQL在报表统计里更有优势
疾控系统里有大量多表关联查询和条件统计，比如"按传染病类型统计某时间段内的报告数""按疫苗接种批次追踪异常反应率"。MyBatis的核心特点是SQL由开发者自己写，完全可控。你可以在XML里精确控制每个JOIN、每个WHERE条件，查询性能心里有数。
有些人会问：MyBatis-Plus不是更方便吗？确实，单表CRUD它能省掉大量Mapper方法。但疾控系统的业务中，复杂的统计查询才是大头，单表操作占比并不高。而且项目里如果混用MyBatis-Plus的LambdaQueryWrapper和自定义XML查询，反而会让数据访问层的风格不统一，维护起来别扭。这套系统选择原生MyBatis，主要就是保证SQL的可读性和可控性。
顺便说一个实用工具：IDEA里装一个MyBatis Log Free插件，能把MyBatis执行时预编译的SQL和参数自动拼接打印出来，排查动态SQL问题时极其好用。后面讲动态SQL时我会具体演示。
2.3 Vue3+Element Plus：后台管理系统的效率之选
疾控系统的前端本质是一个后台管理系统：左侧菜单、顶部栏、表格、表单、弹窗、统计面板。Vue3的组合式API让组件逻辑复用更舒服，Element Plus则直接把表格、表单校验、日期选择器、分页这些高频组件封装好了。
选Vue3还有个现实原因：生态已经非常成熟。你搜"vue3后台管理系统"，能找到大量现成的脚手架和模板。对做疾控系统这类偏传统管理的项目，不需要SSR、不需要微前端，一个标准的Vite + Vue3 + Vue Router + Pinia + Element Plus工程就足够了。
2.4 MySQL：疾控数据存储的稳妥选择
MySQL在中小型管理系统里是绝对的主流。疾控系统的数据量级——一个区县级疾控中心，传染病报告每月几千条、疫苗接种记录每天几百条、重点人群档案几千份——MySQL完全扛得住。关键是要把字符集、排序规则、时区这些基础配置弄对，否则后面会出现中文乱码、时间差8小时等一堆让人抓狂的问题。
3. 数据库设计是系统的地基——疾控业务怎么映射成表结构
这套系统的数据库设计我认为是整个项目里最值得研究的部分。它没有用特别复杂的表结构，但把疾控业务的核心关系表达得很清楚：人员、事件、行为、统计。
3.1 核心业务表设计
我按模块拆开讲。
传染病报告管理是这个系统的核心模块。核心表是infectious_report，字段包括：报告卡编号、患者姓名、身份证号、性别、出生日期、现住址、传染病名称、诊断时间、报告时间、报告人、审核状态。这里有个业务细节：一套完整的传染病报告流程包含"报卡——审核——确认——上报"四个状态，所以表里必须有一个report_status字段，用int类型存状态码，0待审核、1已审核、2已上报、3已退回。
疫苗接种管理涉及两张核心表：vaccine_stock（疫苗库存表）和vaccination_record（接种记录表）。疫苗库存表要记录疫苗名称、批号、生产厂家、有效期、入库数量、剩余数量。接种记录表记录接种人、接种疫苗、接种日期、接种剂次、接种医生、留观状态。这里最关键的关联字段是vaccine_batch_no（批号），通过批号可以追溯某批次疫苗打了哪些人，这是疾控应急事件中"疫苗召回"功能的数据基础。
重点人群管理主要针对慢性病患者、老年人、孕妇等需要长期随访的人群。核心表是key_population（重点人群档案表）和follow_up_record（随访记录表）。档案表存基本信息、人群类型、建档医生、建档日期；随访记录表存随访日期、随访方式、血压/血糖等体征数据、随访结论。
系统管理部分就是常规的sys_user、sys_role、sys_menu三张表，做RBAC权限控制。
3.2 字段设计的几个关键细节
- 主键策略：所有业务表主键用BIGINT自增，不要用UUID。原因很简单：UUID作为主键会导致索引碎片化，数据量大时查询性能下降。疾控系统的并发量不高，自增主键MySQL维护起来最省心。
- 逻辑删除：每条业务表都加
deleted字段，默认0。用户误删一条传染病报告，不能物理删除，必须是逻辑删除保底，这是疾控行业审计的要求。 - 创建时间和更新时间：加
create_time和update_time，类型为datetime。插入和更新时在Java代码里用LocalDateTime.now()统一填充。 - 状态字段用int不用varchar：比如审核状态、接种状态、随访状态，用int存枚举值，配合Java里的枚举类做映射，避免字符串拼写不一致的问题。
- 患者身份证号加密存储：疾控数据涉及个人隐私，身份证号、手机号不能明文存。项目里用的是AES加密后再入库，查询的时候解密返回。这个点在实际评审和答辩中非常加分。
3.3 索引怎么建才合理
疾控系统查询场景相对固定：传染病报告按报告时间范围查、按传染病名称查；接种记录按接种人身份证查；重点人群按人群类型和建档时间查。索引设计就围绕这些查询条件来建。
infectious_report表在report_time和disease_name上建联合索引，因为统计报表基本都按"疾病+时间范围"来查询。vaccination_record表在id_card上建普通索引，因为查询某人的接种记录是最高频操作。follow_up_record表在key_person_id上建索引。
我见过不少人一上来给所有字段都加索引，结果插入数据变慢、索引文件膨胀。其实像疾控系统这个量级，每张表3到5个索引足够了。这条经验是从实际系统维护里换来的，索引不是越多越好，而是越贴合查询模式越好。
4. 后端实现链路——SpringBoot+MyBatis在疾控场景下的关键代码设计
后端这部分我不打算贴完整源码，重点讲清楚几条核心链路的代码组织和SQL写法，这些都是真正动手写项目时需要理解的地方。
4.1 项目分层与请求流转
一个标准的SpringBoot后端工程分这么几层：Controller（接收请求、参数校验、返回结果）、Service（业务逻辑）、Mapper（数据访问）。DTO用于接收前端参数，VO用于返回前端数据，Entity对应数据库表。
疾控系统的请求流转我用传染病报告审核这个功能举例：
- 前端调用
POST /api/report/audit接口，传reportId和auditResult。 - Controller接收后调用
ReportService.audit()方法。 - Service层做状态校验（比如判断当前状态是否为"待审核"），然后调用
ReportMapper.updateStatus()更新数据库。 - 返回统一Result对象，前端根据code判断成功失败。
这套流程看起来简单，但有两个细节必须注意：
- 事务控制：审核动作不只要更新报告状态，可能还要插入一条审核记录到
report_audit_log表。这两个操作必须放在同一个事务里，用@Transactional注解。否则状态更新了但日志没插入，出了问题根本没法追溯。 - 状态机校验：在Service层必须校验当前状态是否允许流转。比如已上报的报告不能回退到待审核，这个逻辑放在Controller层校验是防不住并发请求的，必须在Service层加。
4.2 MyBatis动态SQL的实际应用——条件统计查询
疾控系统里最典型的复杂查询场景：综合查询传染病报告列表，支持按疾病名称、报告状态、报告时间段、报告人等多个条件任意组合筛选。如果用Java代码拼SQL，条件一多代码就变得又臭又长。MyBatis的<where>标签完美解决这个问题。
<select id="selectReportList" resultType="com.example.entity.InfectiousReport"> SELECT * FROM infectious_report <where> <if test="diseaseName != null and diseaseName != ''"> AND disease_name = #{diseaseName} </if> <if test="reportStatus != null"> AND report_status = #{reportStatus} </if> <if test="startTime != null"> AND report_time >= #{startTime} </if> <if test="endTime != null"> AND report_time <= #{endTime} </if> <if test="reporterName != null and reporterName != ''"> AND reporter_name LIKE CONCAT('%', #{reporterName}, '%') </if> </where> ORDER BY report_time DESC </select><where>标签会自动处理第一个条件前面的AND关键字，不需要写"WHERE 1=1"，这是很多人从老项目里带过来的坏习惯，在MyBatis里完全没必要。
还有一个实际开发中容易踩的坑：report_time字段是datetime类型，前端传过来的时间范围是String类型的"2024-01-01 00:00:00"，直接用>=和<=比较没问题。但如果前端传的是"2024-01-01"这种日期格式，直接比较会把结束日期当天的数据漏掉。正确做法是后端把结束时间加一天再比较，或者SQL里用DATE(report_time) <= #{endTime}。这个问题在疾控统计报表里经常出现，查出来的数据少一天，你排查半天都想不到是这个原因。
4.3 参数校验与统一异常处理
疾控系统涉及很多必填字段：患者姓名、传染病名称、诊断时间、报告时间，这些字段丢失会造成数据质量严重下降。项目里的做法是使用@Validated注解加自定义DTO校验：
public class ReportAddDTO { @NotBlank(message = "患者姓名不能为空") private String patientName; @NotBlank(message = "传染病名称不能为空") private String diseaseName; @NotNull(message = "诊断时间不能为空") @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss") private LocalDateTime diagnosisTime; }统一异常处理这块，项目里定义了一个GlobalExceptionHandler，用@RestControllerAdvice捕获业务异常和参数校验异常，统一返回Result.error(code, message)结构。这里有个连很多有经验的人都会忽略的问题：@JsonFormat序列化LocalDateTime时，如果前端传的是"yyyy-MM-dd"格式而不是带时分秒的格式，会直接报反序列化异常。所以前端传日期参数时，必须和后端约定的pattern保持一致，否则接口报错你半天找不到原因。
4.4 MyBatis缓存问题——疾控系统里容易忽略的隐患
热搜词里有"mybatis缓存"，这里必须专门提醒一下：MyBatis一级缓存是SqlSession级别的，同一个SqlSession中执行两次相同的查询，第二次会命中缓存，但这在SpringBoot + MyBatis集成环境下，因为SqlSession每次操作都会新建（默认配置下），一级缓存基本形同虚设，不会出问题。
真正要注意的是二级缓存。如果某个Mapper配置了二级缓存，那么更新操作后其他查询可能会查到旧数据。疾控系统里疫苗接种记录是高频更新的数据，如果开了二级缓存又没有正确配置刷新策略，会出现"新增了接种记录但列表查不到"的诡异问题。我的建议是：这类管理系统默认全关二级缓存，Mapper XML里不写<cache/>标签。性能完全够用，还省掉一大类缓存一致性问题。
5. 前端Vue3实现——后台管理界面的搭建思路与关键交互
疾控系统的前端，说白了就是把后端接口数据用表格、表单、图表的方式呈现出来，让防疫人员能快速完成录入和查询。Vue3在这里的核心优势就是组件化开发带来的高效率。
5.1 工程初始化和路由/状态管理
推荐用Vite创建工程：npm create vite@latest cdc-web -- --template vue。然后安装Vue Router、Pinia、Element Plus、Axios。工程结构按模块划分：
src/api/：按后端模块拆分的接口定义文件，比如report.js、vaccine.js、followUp.jssrc/views/：页面组件，比如report/ReportList.vue、report/ReportAudit.vue、vaccine/VaccineStock.vuesrc/router/：路由配置，用懒加载方式引入页面组件src/store/：Pinia状态管理，主要存用户信息和登录状态
路由守卫要做登录拦截：没登录跳转到登录页。疾控系统涉及个人隐私数据，不能让未认证用户直接访问任何业务页面。
Axios封装有两件事必须做：请求拦截器里带上Token，响应拦截器里统一处理业务错误码和HTTP 401状态。比如Token过期，前端自动跳登录页并给出提示，这个体验细节对系统可用性影响很大。
5.2 核心页面：传染病报告列表的双向数据流
以传染病报告列表页为例，这个页面是所有业务页面里最典型的：顶部是查询表单（疾病名称下拉框、报告状态下拉框、时间范围选择器、查询/重置按钮），中间是操作按钮（新增报告、导出Excel），下面是数据表格（分页展示）。
Vue3的组合式API让这个页面的逻辑非常清晰。核心代码逻辑大致是：
const queryParams = reactive({ diseaseName: '', reportStatus: null, startTime: null, endTime: null, pageNum: 1, pageSize: 10 }) const tableData = ref([]) const total = ref(0) async function fetchList() { const res = await getReportList(queryParams) tableData.value = res.data.rows total.value = res.data.total } function handleQuery() { queryParams.pageNum = 1 fetchList() }查询表单里的重置按钮有个细节：重置时要把时间范围选择器的值置空，而不是置为默认值，否则用户每次进来都会带着默认时间范围的限定，查不到更早的数据。很多初学Vue3的人在封装表单组件时容易忽略这个交互细节。
5.3 疫苗接种模块的前端状态联动
疫苗接种记录新增页面是一个多级联动的表单：选择疫苗名称后，疫苗批号下拉框只显示该疫苗当前有库存的批号；选择了批号后，显示该批次的剩余库存量和有效期。这个联动效果用Vue3的computed或watch都可以实现。
我推荐用computed，因为它天然适合"根据已有响应式数据计算新数据"的场景。比如：
const availableBatchList = computed(() => { if (!form.vaccineName) return [] return vaccineStockList.value.filter(item => item.vaccineName === form.vaccineName && item.stockCount > 0) })这里有一个业务校验很容易漏：选择了批号之后，接种数量不能超过该批次的剩余库存。这是"疫苗出库与接种记录同步"的关键，否则会出现库存明明不够还继续接种的严重业务错误。前端校验一层，后端Service层必须再校验一层，两层校验缺一不可。
5.4 统计面板的简易可视化
疾控系统需要一个首页统计面板：本周新增传染病报告数、本月接种剂次、重点人群随访完成率、各疾病报告趋势图。这类统计图表使用ECharts，在Vue3里封装一个通用图表组件，后端提供一个聚合统计接口返回JSON数据，前端直接渲染。
这里想提醒一点：图表不是越复杂越好。疾控中心领导要看的就几个核心数字和趋势，一个折线图展示近30天传染病报告趋势、一个饼图展示传染病类型分布基本就够了。把接口吞吐量、响应时长这类技术指标放在业务面板上，反而干扰决策。
6. 前后端联调与部署——跨域、时区、版本兼容这些坑我都替你踩过了
这部分内容全是真金白银换来的经验。项目写完了，联调和部署才是真正让人抓狂的阶段。我把最常遇到的几个问题列出来，你遇到的时候直接对照排查。
6.1 跨域问题：开发环境用代理，生产环境用Nginx
开发环境下，前端跑在Vite的5173端口，后端跑在SpringBoot的8080端口，两个端口不同必然产生跨域。
很多人的第一反应是在后端加@CrossOrigin注解或全局CORS配置。这在开发阶段确实能解决问题，但生产环境部署时，前端静态文件由Nginx托管，后端接口也通过Nginx反向代理转发，此时跨域配置如果还在后端放行所有来源，等于把接口完全暴露，存在安全隐患。
我推荐的方案是：开发环境在前端Vite配置代理转发，生产环境统一由Nginx转发。
// vite.config.js server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }生产环境Nginx配置：
location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }这样前后端完全同源，不存在跨域，Cookie和认证信息的携带也简单很多。
6.2 MySQL时区问题：查询结果慢了8小时
这个坑十个项目九个踩。MySQL连接串里不加serverTimezone参数或者设置不正确，Java里查询出来的时间会比数据库实际存储的时间少8小时。原因很简单：MySQL的datetime类型不携带时区信息，但MySQL JDBC驱动在转换时间时默认使用服务器时区，如果MySQL服务器时区是UTC，而JVM默认时区是东八区，就会出现8小时的偏差。
解决办法是在JDBC连接串中明确指定：
jdbc:mysql://localhost:3306/cdc_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai同时建议MySQL数据库安装时就把时区设置为+08:00，命令是SET GLOBAL time_zone = '+08:00'。前后端传时间参数时统一用带时区的ISO格式，避免各层自行转换造成混乱。
6.3 SpringBoot版本过高导致的依赖地狱
前面提过SpringBoot 3.x需要JDK 17，但很多人的开发环境还是JDK 8。如果强行用SpringBoot 3.x，会遇到javax包名改成jakarta、MyBatis相关starter不兼容等一堆问题。
用SpringBoot 2.7.x + JDK 8是最稳妥的组合。这不算技术落后，你在很多企业实际项目中依然能看到大量2.x版本。做疾控系统这种业务重、技术求稳的项目，稳定压倒一切。
6.4 打包部署的实操步骤
后端打包，确保pom.xml里配置了SpringBoot的Maven插件，执行mvn clean package -DskipTests，生成target/cdc-system.jar，然后用java -jar cdc-system.jar启动。
前端打包，执行npm run build，生成dist/目录，把整个目录的静态文件扔给Nginx托管。
这里有个部署上的细节：前端路由如果用history模式，刷新页面时Nginx会404，必须配置try_files回退到index.html。
location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }这个配置忘掉的话，你在系统里从列表页跳详情页没问题，但一按F5刷新就白屏报404，排查起来能急死人。
6.5 动态SQL排查利器：MyBatis Log Free
联调阶段如果一个条件查询查出来的结果不对，最有效的排查方式就是看MyBatis实际执行的SQL长什么样。在IDEA插件市场装一个MyBatis Log Free，控制台会自动把参数替换好的完整SQL打印出来。
比如你明明传了reportStatus=1，查出来的结果却包含了状态为0的数据，用这个插件一看SQL，发现动态SQL里某个if条件没生效，问题一目了然。这个工具是我做MyBatis项目时的必备工具，强烈建议装上。
7. 从这套源码出发的扩展方向——别停留在"能跑"，想想"能用好"
很多人拿到一套源码，跑通之后就觉得完事了。但一个能从毕业设计演变成真正能被疾控机构使用的系统，还需要在几个方向上继续打磨。
权限控制的精细化。目前系统如果只做了简单的角色区分（管理员、普通用户），建议往数据权限方向扩展——不同科室的医生只能看到自己科室管的传染病报告，区级疾控中心可以看到全区数据。这个通过MyBatis拦截器给SQL自动追加数据权限条件就能实现，是MyBatis的高级玩法，也很能体现技术水平。
批量录入的体验优化。防疫工作人员最怕表单一条条录。考虑Excel批量导入功能，在POI解析Excel的基础上做一个导入模板下载、数据校验、错误行提示。这个功能在实际使用中反馈最好，属于短平快但价值很高的增强。
可视化大屏。疾控中心经常有汇报展示需求，把传染病实时数据、疫苗接种覆盖率、重点人群随访情况做成大屏展示，用Vue3配合ECharts轮询接口数据，视觉效果直接拉满。这个方向适合做项目包装，也适合放在简历里作为亮点。
消息提醒机制。到期未随访的重点人群、库存过期的疫苗批次，都可以推送给相关用户。用SpringBoot的定时任务加WebSocket或者集成消息队列就能实现，业务价值非常明确。
我在实际接触这类疾控系统的过程中，最大的体会是：技术的复杂度反而不是难点，难点在于理解业务——为什么随访记录要绑档案，为什么疫苗库存和接种记录必须严格联动，为什么报告审核状态不能随意回退。这些业务逻辑理解透了，数据库设计和接口设计自然就顺了。你如果是拿这套项目去面试或答辩，除了讲清楚技术栈和功能模块，多讲讲业务上的数据流转和边界处理，会让面试官和评委真正觉得你有项目思维，而不只是在堆功能。
最后分享一个我在联调阶段养成的小习惯：每写完一个模块，先用Postman或Apifox把后端接口全部自测一遍，再让前端对接。等前后端联调时，问题主要集中在参数格式和数据结构上，而不是业务逻辑本身。这样联调效率会高非常多。做疾控系统这种业务逻辑严谨的项目，把接口层测透了，后面就都是水到渠成的事。
