手里这套“Java SpringBootVue3MyBatis 疾病防控综合系统”源码我自己断断续续改了大概三周。做之前以为就是个普通的管理系统真正动手才发现疾病防控这个业务场景比一般的CRUD系统难在数据流转和状态管理上病例从发现、上报、审核、复核到转归每一步都有严格的流程要求而且报表统计、趋势分析这类需求特别多。如果你正准备拿这套源码做毕业设计、面试项目或者想自己从零搭一套前后端分离管理系统那这篇文章应该能帮你少踩不少坑。先说明一下整个系统的骨架后端是SpringBoot 2.7 MyBatis MySQL 8.0前端是Vue3 Vite Element Plus前后端完全分离通过RESTful API通信鉴权用的是JWT。这个技术栈组合在当前Java全栈项目里算比较主流既不会太老也没有激进到会给新手造成额外负担。这套系统我实际跑下来的感受是功能模块完整度很高健康档案、风险上报、流调记录、物资台账、数据分析看板、用户权限管理都有代码结构也清晰适合二次开发和扩展。下面我按实际开发顺序把整个系统的设计思路、核心实现和踩坑过程详细拆开讲。1. 项目整体设计与技术栈选型为什么我最终选了这套组合1.1 从需求反推技术选型先聊选型。很多人上来就纠结“SpringBoot还是SSM”“Vue3还是Vue2”但我的习惯是先看业务。疾病防控综合系统这类项目核心需求可以拆成三块一是多角色数据上报和审核二是大量病例数据的登记和检索三是基于时间维度的统计分析和可视化。这三块需求决定了技术选型的方向。后端用SpringBoot几乎是必然选择社区生态成熟自动配置大大减少了XML配置的繁琐程度内嵌Tomcat也省去了单独部署Web服务器的步骤。MyBatis则是因为这类业务系统SQL复杂动态条件检索多用MyBatis可以在XML里精细控制SQL比JPA那种“帮你生成好一切”的方式更可控也更容易排查性能问题。MySQL做数据库不用多说开源免费、部署简单、性能足够。前端选Vue3而不是Vue2核心原因是Composition API在复杂业务页面里的组织能力更强而且Vite构建速度比Webpack快一个量级开发体验完全不一样。Element Plus作为Vue3对应的组件库表格、表单、日期选择器这些后台管理常用的组件都很齐全能省不少时间。这里顺便说下这套系统的数据可视化看板用的是ECharts。市面上有些系统会集成大而全的DataV、AntV等可视化框架但ECharts按需引入后体积可控、文档全、网上示例多在这个体量下性价比是最高的。1.2 前后端分离的分工与模块规划前后端分离这个词很多人挂在嘴边但真正落地时容易分不干净。我的划分原则很简单后端只负责数据和业务规则前端只负责交互和展示。比如“审核病例”这个操作后端接口只接收病例ID和审核结果返回成功或失败至于审核按钮怎么渲染、弹窗怎么写都是前端的事。系统功能模块按业务域可以拆成这几块健康档案管理人员基本信息、联系方式、健康状况、既往病史等基础信息维护。风险监测与上报疑似/确诊情况的上报、审核、复核支持批量导入。流调信息管理病例活动轨迹、密切接触者关联、流调报告附件。物资管理防护物资、消杀物资、药品的入库、出库、库存预警。数据分析看板按地区、时间、人群维度统计新增、治愈、转归等指标。系统管理用户、角色、菜单、字典、操作日志。模块划分清楚之后前后端并行开发就很顺畅。我在实际开发时先定接口文档前端用Mock数据先行开发后端按照接口文档同步开发最后联调时问题就少很多。1.3 权限模型RBAC与多角色数据隔离权限设计是这类系统的重头戏。疾病防控系统角色天然就多系统管理员、疾控中心人员、医疗机构上报员、基层排查人员、只读访客等。我采用的是一套标准的RBAC基于角色的访问控制模型用户关联角色、角色关联菜单和操作权限同时给每个用户挂一个数据归属单位字段用单位ID做数据隔离。数据隔离这块容易踩坑。比如市级账号应该能看到下辖区县的数据而区县级账号只能看本区的数据。如果只做菜单权限就会出“越权查看”的问题。我的处理方式是在后端查询时自动拼接单位层级条件核心SQL强制带上WHERE unit_id IN (SELECT id FROM unit WHERE path LIKE xxx%)这类条件从接口层规避数据越权。2. 数据库设计疾病防控系统的核心其实是表结构2.1 主业务表拆解与关系设计这类系统的技术难点不在增删改查而在表结构能不能支撑复杂业务。我画完ER图之后最大的感受是业务表可以多但不能乱关键要理清主表和流水表的关系。以“病例”为例我先建了一张person表保存人员静态信息包括姓名、身份证号、性别、年龄、联系电话、现住址等。身份证号是天然的幂等键一个人只能有一条健康档案。然后针对每次上报建一张report_record流水表记录上报时间、上报单位、症状描述、检验结果、风险等级、审核状态、审核意见。这样设计的好处是一个人可以有多次上报记录但只有一条最新状态既保住了历史轨迹又方便取“当前状态”。流调信息我单独建了trace_record表存活动轨迹表格数据时间点、地点、停留时长、接触人员类别。每条流调记录都关联report_id形成一对多的关系。物资表和审批表也都是典型的流水表设计这里不展开。2.2 病例状态机用数据库字段管理业务流转这是我做这个项目收获最大的一部分。病例状态不能靠“改个字段就完事”得设计成状态机。我把状态定义为待审核、已审核、待复核、已复核、已排除、已转归。每个流转节点在业务代码里都做合法性校验比如“已排除”的病例不能直接跳到“已转归”必须经过复核环节。具体到数据库设计我的做法是在report_record表里加两个字段status当前状态和version乐观锁版本号。更新时使用UPDATE report_record SET status #{newStatus}, version version 1 WHERE id #{id} AND version #{oldVersion}这样能防止并发操作导致状态错乱。这个设计在多人同时审核的场景下非常重要实战中真的遇到过两个审核员同时审同一份上报、导致旧数据覆盖新数据的情况。2.3 查询优化与索引设计疾病防控系统的查询有一个特点列表页条件多但每次查询的数据量其实有限。我建索引的原则是“先满足等值查询再优化范围查询”。核心表索引设计供参考person表id_card建唯一索引name建普通索引unit_id建普通索引。report_record表person_id建索引report_time建复合索引(unit_id, report_time)。trace_record表report_id建普通索引activity_time建普通索引。索引不是越多越好写多读少的表索引多了反而拖慢插入速度。我实际测试过优化索引后百万级数据量下复合条件查询基本稳定在200ms以内完全够用。另外所有状态字段我用TINYINT存数字枚举值不用字符串这样既能节省空间查询也更快但需要在代码里维护好枚举映射关系。3. 后端实现SpringBoot MyBatis的落地细节3.1 工程分层与JWT认证后端工程我按标准的三层结构组织controller接口层、service业务层、mapper数据访问层另外加entity、dto、vo三层对象模型。一个容易被忽略的细节是entity对应数据库表结构dto接收前端参数vo返回前端数据三者不能混用。很多初学者喜欢一个实体类走天下图省事结果页面多一个字段就报错后面维护起来非常痛苦。认证用的是JWT流程是登录成功后后端生成token返回给前端前端把token存到localStorage每次请求在请求头带Authorization: Bearer token后端拦截器校验token并解析出用户信息和权限列表。JWT的过期时间我设的是12小时同时做了token续期逻辑在过期前1小时内访问接口就自动发新token。这里注意JWT的密钥必须放到application.yml的独立配置项里别硬编码在代码里。3.2 MyBatis动态SQL复杂查询的杀手锏MyBatis最大的优势就是动态SQL。疾病防控系统的查询条件极多比如病例列表要支持按姓名模糊查询、按状态筛选、按时间范围筛选、按风险等级筛选而且这些条件可以任意组合。用if标签可以很优雅地解决select idselectReportList resultTypecom.example.vo.ReportVO SELECT r.id, p.name, p.id_card, r.status, r.risk_level, r.report_time, r.audit_status FROM report_record r LEFT JOIN person p ON r.person_id p.id where if testname ! null and name ! AND p.name LIKE CONCAT(%, #{name}, %) /if if teststatus ! null AND r.status #{status} /if if teststartTime ! null AND r.report_time gt; #{startTime} /if if testendTime ! null AND r.report_time lt; #{endTime} /if /where ORDER BY r.report_time DESC LIMIT #{offset}, #{pageSize} /select用where标签的好处是它自动处理掉第一个条件前面的AND不用自己写WHERE 11这种丑写法。每次看到初学者写WHERE 11我都会劝改掉虽然结果一样但可读性和执行计划都有差异。还有一个容易踩坑的点是if teststatus ! null判断的是Java属性如果入参是包装类型一定要判断是否为空否则MyBatis会报There is no getter for property named xxx之类的异常。另外需要先判断状态字段是否是空字符串时用status ! null and status ! 两个条件都不能少。3.3 大名单上报场景下的批量插入优化疾病防控系统有一个高频操作批量上报。可能是几十条也可能是一次性上千条人员名单导入。最开始我用循环单条插入结果导入2000条数据花了将近10秒根本没法用。后来改成MyBatis的foreach批量插入性能提升非常明显insert idbatchInsert parameterTypelist INSERT INTO report_record ( person_id, status, risk_level, report_time, report_unit_id, symptom_desc, create_time ) VALUES foreach collectionlist itemitem separator, (#{item.personId}, #{item.status}, #{item.riskLevel}, #{item.reportTime}, #{item.reportUnitId}, #{item.symptomDesc}, NOW()) /foreach /insert2000条数据的插入时间从10秒降到了1秒左右效果立竿见影。但这里有两个坑必须注意一是MySQL默认会校验max_allowed_packet超过这个大小的SQL会被拒绝批量插入条数过多时需要调大该参数二是foreach拼接SQL有长度限制我实际测试单批500条比较安全数据量大时分批提交。如果你使用的是MyBatis-Plus它有内置的saveBatch方法底层同样走批量插入但有一个配置项需要留意JDBC连接串要加上rewriteBatchedStatementstrue否则预编译语句不会真正合并执行MyBatis-Plus的批量插入性能提升会大打折扣。这套源码用的是原生MyBatis也值得了解这一点方便以后迁移。3.4 启动项与配置文件里的几个坑这部分要重点说因为我在这上面浪费了不少时间。SpringBoot版本问题在热词里频繁出现确实是个高频坑。之前遇到过SpringBoot 3.x版本配JDK 8启动直接报错的场景因为SpringBoot 3.0开始强制要求JDK 17以上。如果你本机装的是JDK 8老老实实用SpringBoot 2.7.x别追新版本。版本号不是越高越好而是要和JDK版本匹配。另一个坑是首次启动Maven依赖下载卡在downloading...不动。原因是默认走了Maven中央仓库国内网络访问慢。解决办法是在settings.xml里配置阿里云镜像仓库mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror配置完之后依赖下载速度直接翻几倍。还有java: OutOfMemoryError: Insufficient Memory这个问题多半是IDEA里Maven编译时内存不够。解决办法是在Help - Change Memory Settings里调大IDEA的堆内存同时在maven的VM options里加-Xmx1024m。如果是运行SpringBoot应用爆内存则在启动配置的VM options里调整-Xms256m -Xmx512m能缓解大部分内存不足的情况。3.5 自定义Banner一个提升体验的小细节热词里出现了“springboot banner生成器”这里顺带说一个提升项目格调的小技巧。SpringBoot启动时默认打印的那个Spring图案太单调了你可以去网上搜“Spring Boot Banner Generator”在线生成一段ASCII艺术字把生成的内容保存到src/main/resources/banner.txt里。启动项目时就会显示你自定义的图案比如系统名称。这个操作不复杂但要提醒一句banner.txt不要用中文部分终端对中文ASCII艺术字的显示宽度处理不一致会出现错位。我用过一次中文直接乱码后来全换成英文才正常。4. 前端实战Vue3 Element Plus的实施记录4.1 前端工程初始化与目录规划前端我用Vite创建Vue3项目命令是npm create vitelatest frontend -- --template vue然后安装element-plus、axios、vue-router、pinia、echarts这几个核心依赖。Vite项目的驱动速度比Webpack快太多了热更新基本是秒级开发体验提升明显。目录规划供参考src/ ├── api/ # 接口请求封装 ├── assets/ # 静态资源 ├── components/ # 通用组件 ├── layout/ # 布局组件 ├── router/ # 路由配置 ├── stores/ # pinia状态管理 ├── utils/ # 工具函数 └── views/ # 页面组件这里有一个实操建议api目录下每个模块单独建一个文件比如report.js、person.js、equipment.js文件里导出一个个方法对应后端接口。不要在页面上直接写axios.get(/api/xxx)否则接口一多、地址一变改起来想哭。4.2 组合式APIcomputed、watch与hooks复用Vue3开发让我最舒服的是Composition API。以前Vue2里业务逻辑分散在data、methods、watch这些选项里遇到复杂页面要反复上下拖动找代码。现在可以按业务维度组织script setup import { ref, computed, onMounted } from vue import { getReportList } from /api/report const loading ref(false) const tableData ref([]) const queryParams ref({ status: null, keyword: , pageNum: 1, pageSize: 10 }) const total ref(0) const isFiltering computed(() { return queryParams.value.status ! null || queryParams.value.keyword ! }) async function fetchList() { loading.value true try { const res await getReportList(queryParams.value) tableData.value res.data.records total.value res.data.total } finally { loading.value false } } async function handleReset() { queryParams.value { status: null, keyword: , pageNum: 1, pageSize: 10 } await fetchList() } onMounted(fetchList) /scriptcomputed在这里用来派生“当前是否处于筛选状态”这种依赖其他响应式数据自动更新的逻辑在Vue2的computed里也有但配合script setup写法整体代码量少了很多。搜索、重置、分页、刷新这几个操作通过统一调用fetchList来更新表格逻辑链路很清晰。条件渲染也需要注意一点Vue3中动态表格列和表单域很多人在v-for和v-if同时用在一处时收到编译警告。它们的优先级在Vue3里和Vue2不一样同元素上同时使用很容易产生逻辑问题。我的建议是要么拆层标签要么用computed先过滤再遍历不要在同一元素上同时写。4.3 两个高频样式与组件问题用Element Plus做后台管理会遇到两个高频问题一是修改Tabs标签页样式二是富文本编辑器兼容性。Tabs标签页样式定制需要检查浏览器渲染出来的class名称在style langscss scoped里直接用:deep()穿透样式隔离即可。比如想改Tab的选中色:deep(.el-tabs__item.is-active) { color: #2f6fed; font-weight: 600; }:deep()是Vue3处理scoped样式穿透的标准写法Vue2里用的/deep/和在Vue3里不建议使用。富文本编辑器这块要重点提一下热词里出现了“vue-quill-editor vue3”这里有个很常见的坑。vue-quill-editor这个库主要为Vue2设计在Vue3里使用会有兼容性问题。我的建议是不要硬折腾直接换用其他支持Vue3的方案。我当时采用的方案是直接封装Quill或者换成vueup/vue-quill安装后注册组件直接使用省心很多import { QuillEditor } from vueup/vue-quill import vueup/vue-quill/dist/vue-quill.snow.css4.4 路由权限与动态菜单前端权限控制的通用做法是登录成功后后端返回当前用户的角色和菜单列表前端动态注册路由并生成侧边栏菜单。具体实现是静态路由只保留登录页、404页等公共页面业务页面全部用router.addRoute()动态添加。这里有一个体验优化的细节动态添加路由后用户直接刷新页面会白屏因为刷新时路由还没注册完。我的处理是在路由守卫里加一个“路由已初始化”的全局标记如果没初始化先初始化再放行否则直接放行。类似这种异步路由控制逻辑写的时候要注意防止死循环。router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) return } if (token !store.routerLoaded) { store.generateRoutes().then(() { next({ ...to, replace: true }) }) return } next() })5. 踩坑记录与排查速查表源码跑通前一定要看5.1 MySQL环境相关mysql安装教程、mysql安装配置、mysql下载官网安装MySQL 8.0时去官网下载免安装版或者用安装包。安装时务必记住root密码安装完成后用mysql -uroot -p测试连接。如果忘记密码需要通过skip-grant-tables模式重置过程比较麻烦尽量一次设好。使用MySQL Workbench时连接如果报Authentication plugin caching_sha2_password错误是因为MySQL 8.0默认认证插件和旧客户端不兼容。要么在Workbench连接配置里改插件要么创建用户时指定mysql_native_password。这个报错在本地开发时非常常见。导入SQL脚本时如果提示Unknown database需要先建库再选择库CREATE DATABASE IF NOT EXISTS disease_control DEFAULT CHARACTER SET utf8mb4;然后USE disease_control;再执行SOURCE导入。编码集推荐统一用utf8mb4能有效避免中文乱码。MySQL中int 5这类“字段直接参与运算”的操作要谨慎。比如统计累加时如果字段是INT类型直接在SQL里UPDATE table SET count count 5是没问题的但要考虑并发场景下丢更新需要配合行锁或乐观锁。mysql update语法的坑更新多表时MySQL的UPDATE JOIN语法和SQL Server、PostgreSQL不太一样注意表别名别省略。另外更新时不小心把WHERE去掉会导致全表更新这种事故我们行业里叫“生产事故预制菜”写更新语句时先确认影响行数再执行。5.2 SpringBoot配置与启动相关springboot版本太高再次强调JDK版本决定SpringBoot大版本。JDK 8选2.7.xJDK 17选3.x。如果已经用了高版本且不想降就把JDK换到对应版本两者必须匹配。springboot配置核心配置文件分application.yml和application-dev.yml开发环境和生产环境分开维护通过spring.profiles.activedev指定生效环境。配置数据库连接时务必加上serverTimezoneAsia/ShanghaiuseSSLfalsecharacterEncodingutf8这些参数避免时区错乱和SSL警告。springboot集成mybatis一直报错最常见的原因是Mapper接口没有被Spring容器扫描到。解决办法是在启动类上加MapperScan(com.example.mapper)或者在每一个Mapper接口上加Mapper注解。两个都加也不会冲突。这个错误报的“No qualifying bean of type”很典型大家遇到别慌先检查扫描路径。eclipse里集成MyBatis报错排查逻辑同IDEA但要注意Eclipse的JDK编译级别默认可能比较低需要手动调成1.8。5.3 MyBatis运行期问题mybatis配置打印开发阶段建议在application.yml里开启SQL日志观察每条SQL的执行情况mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl生产环境记得关掉否则大量日志输出会影响性能。如果用的是MyBatis-Plus生态有log-easy-plus这类插件可以把参数和结果集格式化得更易读不过原生StdOutImpl也够用。mybatis if test indexof有朋友问if testname.indexOf(张) ! -1能不能这么写。答案是能indexOf是Java字符串方法在OGNL表达式里可以调用。但注意如果name为null直接调用indexOf会抛NPE。安全写法是先判空再用字符序列判断if testname ! null and name.indexOf(张) ! -1。不过在SQL里这样用通常没必要直接用LIKE更高效。mybatis缓存MyBatis的一级缓存默认开启作用域是SqlSession在Spring集成环境下多次查询可能共用同一个SqlSession所以会出现“修改数据后查到的还是旧值”的假象。排查思路是检查是不是缓存了对象引用未刷新或者在SQL日志中看是否有新的查询语句执行。二级缓存如果没把握尽量不要开启分布式部署时容易出现脏数据。5.4 常见问题速查表问题现象排查方向推荐解决方式启动依赖下载卡在downloading仓库访问慢或被墙配置阿里云Mirror见上文启动报OutOfMemoryErrorIDEA/Maven内存不足调大IDEA设置里内存参数接口返回401或token失效JWT过期或密钥不一致检查请求头携带token确认前后端密钥一致表格数据中文乱码数据库/连接串编码不一致数据库统一utf8mb4连接串加characterEncodingutf8POST请求跨域报错前后端分离未配置CORS后端加CORS过滤器或CrossOrigin生产用Nginx反向代理同源解决批量插入报PacketTooBigmax_allowed_packet过小调大MySQL该参数并分批插入SQL查询慢缺索引或条件未走索引EXPLAIN分析执行计划补充复合索引最后说几句我个人的实操体会这套系统做下来我最想分享的一点是技术栈本身不难难的是把业务状态梳理清楚。疾病防控系统里大量操作是“改变状态”如果一开始没把状态机设计妥当后面加需求时每一次都要动核心逻辑越改越乱。所以如果你要二开这套源码我强烈建议先把数据库表结构和状态流转摸透再下手改业务代码。还有一个小技巧前端表格里日期格式化反复用可以封装成全局过滤器或者工具函数。包括接口统一的返回结构{ code, msg, data }后端封装好之后所有接口都走同一套规范联调效率和稳定性都会明显提升。另外一个实际经验是开发过程中把application-dev.yml里的MySQL密码、JWT密钥等敏感信息与代码分开维护不要提交到公共仓库。我见过不止一次因为源码连带数据库密码一起泄露出去的案例这个习惯越早养成越好。最后说个扩展方向。这套系统目前看板主要是桌面端我特别建议你可以往移动端适配或消息触达方向扩展比如病例审核通过后给上报人推送一条通知这类需求在实际业务中一定会出现。要是能往这个方向做深整个项目的完整度和面试含金量都会提高不少。
SpringBoot+Vue3+MyBatis疾病防控系统实战：架构设计与踩坑记录
手里这套“Java SpringBootVue3MyBatis 疾病防控综合系统”源码我自己断断续续改了大概三周。做之前以为就是个普通的管理系统真正动手才发现疾病防控这个业务场景比一般的CRUD系统难在数据流转和状态管理上病例从发现、上报、审核、复核到转归每一步都有严格的流程要求而且报表统计、趋势分析这类需求特别多。如果你正准备拿这套源码做毕业设计、面试项目或者想自己从零搭一套前后端分离管理系统那这篇文章应该能帮你少踩不少坑。先说明一下整个系统的骨架后端是SpringBoot 2.7 MyBatis MySQL 8.0前端是Vue3 Vite Element Plus前后端完全分离通过RESTful API通信鉴权用的是JWT。这个技术栈组合在当前Java全栈项目里算比较主流既不会太老也没有激进到会给新手造成额外负担。这套系统我实际跑下来的感受是功能模块完整度很高健康档案、风险上报、流调记录、物资台账、数据分析看板、用户权限管理都有代码结构也清晰适合二次开发和扩展。下面我按实际开发顺序把整个系统的设计思路、核心实现和踩坑过程详细拆开讲。1. 项目整体设计与技术栈选型为什么我最终选了这套组合1.1 从需求反推技术选型先聊选型。很多人上来就纠结“SpringBoot还是SSM”“Vue3还是Vue2”但我的习惯是先看业务。疾病防控综合系统这类项目核心需求可以拆成三块一是多角色数据上报和审核二是大量病例数据的登记和检索三是基于时间维度的统计分析和可视化。这三块需求决定了技术选型的方向。后端用SpringBoot几乎是必然选择社区生态成熟自动配置大大减少了XML配置的繁琐程度内嵌Tomcat也省去了单独部署Web服务器的步骤。MyBatis则是因为这类业务系统SQL复杂动态条件检索多用MyBatis可以在XML里精细控制SQL比JPA那种“帮你生成好一切”的方式更可控也更容易排查性能问题。MySQL做数据库不用多说开源免费、部署简单、性能足够。前端选Vue3而不是Vue2核心原因是Composition API在复杂业务页面里的组织能力更强而且Vite构建速度比Webpack快一个量级开发体验完全不一样。Element Plus作为Vue3对应的组件库表格、表单、日期选择器这些后台管理常用的组件都很齐全能省不少时间。这里顺便说下这套系统的数据可视化看板用的是ECharts。市面上有些系统会集成大而全的DataV、AntV等可视化框架但ECharts按需引入后体积可控、文档全、网上示例多在这个体量下性价比是最高的。1.2 前后端分离的分工与模块规划前后端分离这个词很多人挂在嘴边但真正落地时容易分不干净。我的划分原则很简单后端只负责数据和业务规则前端只负责交互和展示。比如“审核病例”这个操作后端接口只接收病例ID和审核结果返回成功或失败至于审核按钮怎么渲染、弹窗怎么写都是前端的事。系统功能模块按业务域可以拆成这几块健康档案管理人员基本信息、联系方式、健康状况、既往病史等基础信息维护。风险监测与上报疑似/确诊情况的上报、审核、复核支持批量导入。流调信息管理病例活动轨迹、密切接触者关联、流调报告附件。物资管理防护物资、消杀物资、药品的入库、出库、库存预警。数据分析看板按地区、时间、人群维度统计新增、治愈、转归等指标。系统管理用户、角色、菜单、字典、操作日志。模块划分清楚之后前后端并行开发就很顺畅。我在实际开发时先定接口文档前端用Mock数据先行开发后端按照接口文档同步开发最后联调时问题就少很多。1.3 权限模型RBAC与多角色数据隔离权限设计是这类系统的重头戏。疾病防控系统角色天然就多系统管理员、疾控中心人员、医疗机构上报员、基层排查人员、只读访客等。我采用的是一套标准的RBAC基于角色的访问控制模型用户关联角色、角色关联菜单和操作权限同时给每个用户挂一个数据归属单位字段用单位ID做数据隔离。数据隔离这块容易踩坑。比如市级账号应该能看到下辖区县的数据而区县级账号只能看本区的数据。如果只做菜单权限就会出“越权查看”的问题。我的处理方式是在后端查询时自动拼接单位层级条件核心SQL强制带上WHERE unit_id IN (SELECT id FROM unit WHERE path LIKE xxx%)这类条件从接口层规避数据越权。2. 数据库设计疾病防控系统的核心其实是表结构2.1 主业务表拆解与关系设计这类系统的技术难点不在增删改查而在表结构能不能支撑复杂业务。我画完ER图之后最大的感受是业务表可以多但不能乱关键要理清主表和流水表的关系。以“病例”为例我先建了一张person表保存人员静态信息包括姓名、身份证号、性别、年龄、联系电话、现住址等。身份证号是天然的幂等键一个人只能有一条健康档案。然后针对每次上报建一张report_record流水表记录上报时间、上报单位、症状描述、检验结果、风险等级、审核状态、审核意见。这样设计的好处是一个人可以有多次上报记录但只有一条最新状态既保住了历史轨迹又方便取“当前状态”。流调信息我单独建了trace_record表存活动轨迹表格数据时间点、地点、停留时长、接触人员类别。每条流调记录都关联report_id形成一对多的关系。物资表和审批表也都是典型的流水表设计这里不展开。2.2 病例状态机用数据库字段管理业务流转这是我做这个项目收获最大的一部分。病例状态不能靠“改个字段就完事”得设计成状态机。我把状态定义为待审核、已审核、待复核、已复核、已排除、已转归。每个流转节点在业务代码里都做合法性校验比如“已排除”的病例不能直接跳到“已转归”必须经过复核环节。具体到数据库设计我的做法是在report_record表里加两个字段status当前状态和version乐观锁版本号。更新时使用UPDATE report_record SET status #{newStatus}, version version 1 WHERE id #{id} AND version #{oldVersion}这样能防止并发操作导致状态错乱。这个设计在多人同时审核的场景下非常重要实战中真的遇到过两个审核员同时审同一份上报、导致旧数据覆盖新数据的情况。2.3 查询优化与索引设计疾病防控系统的查询有一个特点列表页条件多但每次查询的数据量其实有限。我建索引的原则是“先满足等值查询再优化范围查询”。核心表索引设计供参考person表id_card建唯一索引name建普通索引unit_id建普通索引。report_record表person_id建索引report_time建复合索引(unit_id, report_time)。trace_record表report_id建普通索引activity_time建普通索引。索引不是越多越好写多读少的表索引多了反而拖慢插入速度。我实际测试过优化索引后百万级数据量下复合条件查询基本稳定在200ms以内完全够用。另外所有状态字段我用TINYINT存数字枚举值不用字符串这样既能节省空间查询也更快但需要在代码里维护好枚举映射关系。3. 后端实现SpringBoot MyBatis的落地细节3.1 工程分层与JWT认证后端工程我按标准的三层结构组织controller接口层、service业务层、mapper数据访问层另外加entity、dto、vo三层对象模型。一个容易被忽略的细节是entity对应数据库表结构dto接收前端参数vo返回前端数据三者不能混用。很多初学者喜欢一个实体类走天下图省事结果页面多一个字段就报错后面维护起来非常痛苦。认证用的是JWT流程是登录成功后后端生成token返回给前端前端把token存到localStorage每次请求在请求头带Authorization: Bearer token后端拦截器校验token并解析出用户信息和权限列表。JWT的过期时间我设的是12小时同时做了token续期逻辑在过期前1小时内访问接口就自动发新token。这里注意JWT的密钥必须放到application.yml的独立配置项里别硬编码在代码里。3.2 MyBatis动态SQL复杂查询的杀手锏MyBatis最大的优势就是动态SQL。疾病防控系统的查询条件极多比如病例列表要支持按姓名模糊查询、按状态筛选、按时间范围筛选、按风险等级筛选而且这些条件可以任意组合。用if标签可以很优雅地解决select idselectReportList resultTypecom.example.vo.ReportVO SELECT r.id, p.name, p.id_card, r.status, r.risk_level, r.report_time, r.audit_status FROM report_record r LEFT JOIN person p ON r.person_id p.id where if testname ! null and name ! AND p.name LIKE CONCAT(%, #{name}, %) /if if teststatus ! null AND r.status #{status} /if if teststartTime ! null AND r.report_time gt; #{startTime} /if if testendTime ! null AND r.report_time lt; #{endTime} /if /where ORDER BY r.report_time DESC LIMIT #{offset}, #{pageSize} /select用where标签的好处是它自动处理掉第一个条件前面的AND不用自己写WHERE 11这种丑写法。每次看到初学者写WHERE 11我都会劝改掉虽然结果一样但可读性和执行计划都有差异。还有一个容易踩坑的点是if teststatus ! null判断的是Java属性如果入参是包装类型一定要判断是否为空否则MyBatis会报There is no getter for property named xxx之类的异常。另外需要先判断状态字段是否是空字符串时用status ! null and status ! 两个条件都不能少。3.3 大名单上报场景下的批量插入优化疾病防控系统有一个高频操作批量上报。可能是几十条也可能是一次性上千条人员名单导入。最开始我用循环单条插入结果导入2000条数据花了将近10秒根本没法用。后来改成MyBatis的foreach批量插入性能提升非常明显insert idbatchInsert parameterTypelist INSERT INTO report_record ( person_id, status, risk_level, report_time, report_unit_id, symptom_desc, create_time ) VALUES foreach collectionlist itemitem separator, (#{item.personId}, #{item.status}, #{item.riskLevel}, #{item.reportTime}, #{item.reportUnitId}, #{item.symptomDesc}, NOW()) /foreach /insert2000条数据的插入时间从10秒降到了1秒左右效果立竿见影。但这里有两个坑必须注意一是MySQL默认会校验max_allowed_packet超过这个大小的SQL会被拒绝批量插入条数过多时需要调大该参数二是foreach拼接SQL有长度限制我实际测试单批500条比较安全数据量大时分批提交。如果你使用的是MyBatis-Plus它有内置的saveBatch方法底层同样走批量插入但有一个配置项需要留意JDBC连接串要加上rewriteBatchedStatementstrue否则预编译语句不会真正合并执行MyBatis-Plus的批量插入性能提升会大打折扣。这套源码用的是原生MyBatis也值得了解这一点方便以后迁移。3.4 启动项与配置文件里的几个坑这部分要重点说因为我在这上面浪费了不少时间。SpringBoot版本问题在热词里频繁出现确实是个高频坑。之前遇到过SpringBoot 3.x版本配JDK 8启动直接报错的场景因为SpringBoot 3.0开始强制要求JDK 17以上。如果你本机装的是JDK 8老老实实用SpringBoot 2.7.x别追新版本。版本号不是越高越好而是要和JDK版本匹配。另一个坑是首次启动Maven依赖下载卡在downloading...不动。原因是默认走了Maven中央仓库国内网络访问慢。解决办法是在settings.xml里配置阿里云镜像仓库mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror配置完之后依赖下载速度直接翻几倍。还有java: OutOfMemoryError: Insufficient Memory这个问题多半是IDEA里Maven编译时内存不够。解决办法是在Help - Change Memory Settings里调大IDEA的堆内存同时在maven的VM options里加-Xmx1024m。如果是运行SpringBoot应用爆内存则在启动配置的VM options里调整-Xms256m -Xmx512m能缓解大部分内存不足的情况。3.5 自定义Banner一个提升体验的小细节热词里出现了“springboot banner生成器”这里顺带说一个提升项目格调的小技巧。SpringBoot启动时默认打印的那个Spring图案太单调了你可以去网上搜“Spring Boot Banner Generator”在线生成一段ASCII艺术字把生成的内容保存到src/main/resources/banner.txt里。启动项目时就会显示你自定义的图案比如系统名称。这个操作不复杂但要提醒一句banner.txt不要用中文部分终端对中文ASCII艺术字的显示宽度处理不一致会出现错位。我用过一次中文直接乱码后来全换成英文才正常。4. 前端实战Vue3 Element Plus的实施记录4.1 前端工程初始化与目录规划前端我用Vite创建Vue3项目命令是npm create vitelatest frontend -- --template vue然后安装element-plus、axios、vue-router、pinia、echarts这几个核心依赖。Vite项目的驱动速度比Webpack快太多了热更新基本是秒级开发体验提升明显。目录规划供参考src/ ├── api/ # 接口请求封装 ├── assets/ # 静态资源 ├── components/ # 通用组件 ├── layout/ # 布局组件 ├── router/ # 路由配置 ├── stores/ # pinia状态管理 ├── utils/ # 工具函数 └── views/ # 页面组件这里有一个实操建议api目录下每个模块单独建一个文件比如report.js、person.js、equipment.js文件里导出一个个方法对应后端接口。不要在页面上直接写axios.get(/api/xxx)否则接口一多、地址一变改起来想哭。4.2 组合式APIcomputed、watch与hooks复用Vue3开发让我最舒服的是Composition API。以前Vue2里业务逻辑分散在data、methods、watch这些选项里遇到复杂页面要反复上下拖动找代码。现在可以按业务维度组织script setup import { ref, computed, onMounted } from vue import { getReportList } from /api/report const loading ref(false) const tableData ref([]) const queryParams ref({ status: null, keyword: , pageNum: 1, pageSize: 10 }) const total ref(0) const isFiltering computed(() { return queryParams.value.status ! null || queryParams.value.keyword ! }) async function fetchList() { loading.value true try { const res await getReportList(queryParams.value) tableData.value res.data.records total.value res.data.total } finally { loading.value false } } async function handleReset() { queryParams.value { status: null, keyword: , pageNum: 1, pageSize: 10 } await fetchList() } onMounted(fetchList) /scriptcomputed在这里用来派生“当前是否处于筛选状态”这种依赖其他响应式数据自动更新的逻辑在Vue2的computed里也有但配合script setup写法整体代码量少了很多。搜索、重置、分页、刷新这几个操作通过统一调用fetchList来更新表格逻辑链路很清晰。条件渲染也需要注意一点Vue3中动态表格列和表单域很多人在v-for和v-if同时用在一处时收到编译警告。它们的优先级在Vue3里和Vue2不一样同元素上同时使用很容易产生逻辑问题。我的建议是要么拆层标签要么用computed先过滤再遍历不要在同一元素上同时写。4.3 两个高频样式与组件问题用Element Plus做后台管理会遇到两个高频问题一是修改Tabs标签页样式二是富文本编辑器兼容性。Tabs标签页样式定制需要检查浏览器渲染出来的class名称在style langscss scoped里直接用:deep()穿透样式隔离即可。比如想改Tab的选中色:deep(.el-tabs__item.is-active) { color: #2f6fed; font-weight: 600; }:deep()是Vue3处理scoped样式穿透的标准写法Vue2里用的/deep/和在Vue3里不建议使用。富文本编辑器这块要重点提一下热词里出现了“vue-quill-editor vue3”这里有个很常见的坑。vue-quill-editor这个库主要为Vue2设计在Vue3里使用会有兼容性问题。我的建议是不要硬折腾直接换用其他支持Vue3的方案。我当时采用的方案是直接封装Quill或者换成vueup/vue-quill安装后注册组件直接使用省心很多import { QuillEditor } from vueup/vue-quill import vueup/vue-quill/dist/vue-quill.snow.css4.4 路由权限与动态菜单前端权限控制的通用做法是登录成功后后端返回当前用户的角色和菜单列表前端动态注册路由并生成侧边栏菜单。具体实现是静态路由只保留登录页、404页等公共页面业务页面全部用router.addRoute()动态添加。这里有一个体验优化的细节动态添加路由后用户直接刷新页面会白屏因为刷新时路由还没注册完。我的处理是在路由守卫里加一个“路由已初始化”的全局标记如果没初始化先初始化再放行否则直接放行。类似这种异步路由控制逻辑写的时候要注意防止死循环。router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) return } if (token !store.routerLoaded) { store.generateRoutes().then(() { next({ ...to, replace: true }) }) return } next() })5. 踩坑记录与排查速查表源码跑通前一定要看5.1 MySQL环境相关mysql安装教程、mysql安装配置、mysql下载官网安装MySQL 8.0时去官网下载免安装版或者用安装包。安装时务必记住root密码安装完成后用mysql -uroot -p测试连接。如果忘记密码需要通过skip-grant-tables模式重置过程比较麻烦尽量一次设好。使用MySQL Workbench时连接如果报Authentication plugin caching_sha2_password错误是因为MySQL 8.0默认认证插件和旧客户端不兼容。要么在Workbench连接配置里改插件要么创建用户时指定mysql_native_password。这个报错在本地开发时非常常见。导入SQL脚本时如果提示Unknown database需要先建库再选择库CREATE DATABASE IF NOT EXISTS disease_control DEFAULT CHARACTER SET utf8mb4;然后USE disease_control;再执行SOURCE导入。编码集推荐统一用utf8mb4能有效避免中文乱码。MySQL中int 5这类“字段直接参与运算”的操作要谨慎。比如统计累加时如果字段是INT类型直接在SQL里UPDATE table SET count count 5是没问题的但要考虑并发场景下丢更新需要配合行锁或乐观锁。mysql update语法的坑更新多表时MySQL的UPDATE JOIN语法和SQL Server、PostgreSQL不太一样注意表别名别省略。另外更新时不小心把WHERE去掉会导致全表更新这种事故我们行业里叫“生产事故预制菜”写更新语句时先确认影响行数再执行。5.2 SpringBoot配置与启动相关springboot版本太高再次强调JDK版本决定SpringBoot大版本。JDK 8选2.7.xJDK 17选3.x。如果已经用了高版本且不想降就把JDK换到对应版本两者必须匹配。springboot配置核心配置文件分application.yml和application-dev.yml开发环境和生产环境分开维护通过spring.profiles.activedev指定生效环境。配置数据库连接时务必加上serverTimezoneAsia/ShanghaiuseSSLfalsecharacterEncodingutf8这些参数避免时区错乱和SSL警告。springboot集成mybatis一直报错最常见的原因是Mapper接口没有被Spring容器扫描到。解决办法是在启动类上加MapperScan(com.example.mapper)或者在每一个Mapper接口上加Mapper注解。两个都加也不会冲突。这个错误报的“No qualifying bean of type”很典型大家遇到别慌先检查扫描路径。eclipse里集成MyBatis报错排查逻辑同IDEA但要注意Eclipse的JDK编译级别默认可能比较低需要手动调成1.8。5.3 MyBatis运行期问题mybatis配置打印开发阶段建议在application.yml里开启SQL日志观察每条SQL的执行情况mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl生产环境记得关掉否则大量日志输出会影响性能。如果用的是MyBatis-Plus生态有log-easy-plus这类插件可以把参数和结果集格式化得更易读不过原生StdOutImpl也够用。mybatis if test indexof有朋友问if testname.indexOf(张) ! -1能不能这么写。答案是能indexOf是Java字符串方法在OGNL表达式里可以调用。但注意如果name为null直接调用indexOf会抛NPE。安全写法是先判空再用字符序列判断if testname ! null and name.indexOf(张) ! -1。不过在SQL里这样用通常没必要直接用LIKE更高效。mybatis缓存MyBatis的一级缓存默认开启作用域是SqlSession在Spring集成环境下多次查询可能共用同一个SqlSession所以会出现“修改数据后查到的还是旧值”的假象。排查思路是检查是不是缓存了对象引用未刷新或者在SQL日志中看是否有新的查询语句执行。二级缓存如果没把握尽量不要开启分布式部署时容易出现脏数据。5.4 常见问题速查表问题现象排查方向推荐解决方式启动依赖下载卡在downloading仓库访问慢或被墙配置阿里云Mirror见上文启动报OutOfMemoryErrorIDEA/Maven内存不足调大IDEA设置里内存参数接口返回401或token失效JWT过期或密钥不一致检查请求头携带token确认前后端密钥一致表格数据中文乱码数据库/连接串编码不一致数据库统一utf8mb4连接串加characterEncodingutf8POST请求跨域报错前后端分离未配置CORS后端加CORS过滤器或CrossOrigin生产用Nginx反向代理同源解决批量插入报PacketTooBigmax_allowed_packet过小调大MySQL该参数并分批插入SQL查询慢缺索引或条件未走索引EXPLAIN分析执行计划补充复合索引最后说几句我个人的实操体会这套系统做下来我最想分享的一点是技术栈本身不难难的是把业务状态梳理清楚。疾病防控系统里大量操作是“改变状态”如果一开始没把状态机设计妥当后面加需求时每一次都要动核心逻辑越改越乱。所以如果你要二开这套源码我强烈建议先把数据库表结构和状态流转摸透再下手改业务代码。还有一个小技巧前端表格里日期格式化反复用可以封装成全局过滤器或者工具函数。包括接口统一的返回结构{ code, msg, data }后端封装好之后所有接口都走同一套规范联调效率和稳定性都会明显提升。另外一个实际经验是开发过程中把application-dev.yml里的MySQL密码、JWT密钥等敏感信息与代码分开维护不要提交到公共仓库。我见过不止一次因为源码连带数据库密码一起泄露出去的案例这个习惯越早养成越好。最后说个扩展方向。这套系统目前看板主要是桌面端我特别建议你可以往移动端适配或消息触达方向扩展比如病例审核通过后给上报人推送一条通知这类需求在实际业务中一定会出现。要是能往这个方向做深整个项目的完整度和面试含金量都会提高不少。
