SpringBoot+Vue疾病防控综合系统平台毕设全流程详解

又是一年毕设季后台收到不少同学的私信问疾病防控综合系统平台这类题目怎么做。市面上这类项目源码倒是一抓一大把但大多数要么代码烂得没法看要么接口文档写得像天书SQL脚本能直接导入跑起来的更是少见。这篇就把我个人在做一个SpringBootVue疾病防控综合系统平台过程中的完整思路、技术选型、数据库设计、接口规范、前端页面实现和部署避坑经验全部拆开讲一遍项目源码、SQL脚本、接口文档的编写要点也会一并给出想拿这个题目做Java Web毕设或者打算在此基础上二次开发的同学可以直接参考。做一个完整项目最难的不是某个技术点而是怎么把业务需求翻译成数据结构、再把数据结构翻译成接口和页面。疾病防控这个领域业务边界清晰模块划分相对固定非常适合作为Java Web方向的毕业设计题目。而且这个题目的扩展空间很大——往大了做可以接流调溯源、疫情监测大屏往小了做可以只保留健康档案、疫苗接种预约、物资管理三个核心模块工作量弹性很大适配不同水平的同学。1. 项目概述与业务拆解1.1 疾病防控系统平台到底是做什么的先把这个项目要解决的问题说清楚。疾病防控综合系统平台本质上是基层公共卫生管理工作信息化的一个缩影。传统模式下社区医院的传染病报告靠手工填表、逐级上报疫苗接种记录散落在各个接种点健康宣教活动做完就完了没有数据沉淀。这个系统要做的核心事情就是三件第一把重点人群的健康档案和疾病上报流程数字化第二把疫苗接种、健康宣教、随访管理等日常业务搬上线第三给管理人员提供数据统计和预警看板辅助决策。从这个定位出发系统一定不是单用户的小工具而是多角色、多权限的综合管理平台。我在实际设计时划分了三种角色超级管理员系统管理员、医护人员社区/医院工作人员、普通用户居民/患者。三种角色对应的功能边界完全不同。超级管理员用户管理、角色权限分配、系统日志查看、数据字典维护、系统参数配置医护人员疾病报告录入与审核、健康档案管理、疫苗接种记录登记、随访任务执行、健康宣教内容发布、物资出入库管理普通用户健康档案查看、疾病自查上报、疫苗接种预约、健康资讯浏览、随访反馈填写这个角色划分直接决定了后面的数据库表设计和接口权限控制策略也决定了前端路由的权限拦截逻辑。很多同学做毕设时容易犯的错是一上来就急着建表写代码结果做到一半发现角色和功能对不上又回头改表结构非常耗时。先花半天把角色清单和每个角色的功能清单列出来后面会顺很多。1.2 功能模块怎么划分最合理功能模块的划分我建议按照基础数据 核心业务 统计展示 系统管理四层来做。基础数据包括用户、角色、菜单、区域、疾病类型字典核心业务是疾病上报、健康档案、疫苗接种、随访管理、物资管理、宣教内容统计展示就是各维度的图表系统管理承载日志、权限、配置。这里特别说一下物资管理模块。很多同学以为疾病防控系统只要管病例和档案就够了其实物资管理是这类系统的高频考察点。口罩、消毒液、防护服这类防控物资的入库、出库、库存预警天然适合做成一个独立的供应链小模块而且它涉及的操作逻辑入库单、出库单、库存表、预警阈值很完整用来展示数据库设计和业务逻辑处理能力非常加分。模块划分完毕之后每个模块再往下拆功能点。以疫苗接种管理为例拆出来的功能点有疫苗库存查询、接种预约登记、接种记录录入、接种计划管理、异常反应上报。功能点拆到这种粒度写接口文档时才能做到一个接口对应一个明确的操作前端开发也不会出现不知道调哪个接口的情况。2. 技术选型与工程结构2.1 为什么选SpringBootVue而不是其他组合先聊技术选型的理由。后端用SpringBoot核心原因是它把Spring的配置简化到了近乎零成本内嵌Tomcat可以直接跑jar包配合Spring MVC做RESTful API非常顺手。而且现在市面上主流的毕设管理系统十个里有九个是SpringBoot遇到问题随便一搜就有解决方案这对毕设阶段来说太重要了。前端选Vue的理由类似组件化开发、生态成熟、上手曲线平缓Element UI组件库直接提供表格、表单、弹窗、分页等现成组件能把大量时间从样式调整中解放出来专心做业务逻辑。数据库用MySQL原因不用多说开源免费、学习资料多、Navicat可视化操作方便。ORM框架我用的是MyBatis-Plus它在MyBatis的基础上提供了通用Mapper和条件构造器单表查询基本不用写SQL多表关联查询再手写XML。这一点在开发效率上的提升非常明显尤其是做管理后台这种大量CRUD的系统和报表统计查询时。有一个取舍要说明一下。JPA和MyBatis-Plus二选一时我最终选了MyBatis-Plus。原因很实际毕设答辩时老师大概率会问多表联查怎么做SQL优化怎么做MyBatis-Plus允许你手写SQL和XML映射这比JPA对初学者更友好也更容易把SQL功底展示出来。前端方面脚手架用Vue CLI现在也可以用Vite创建项目路由用Vue Router状态管理用Vuex或PiniaHTTP请求用Axios封装一个统一的请求模块。2.2 后端工程结构怎么组织很多项目源码拿到手第一眼就懵就是因为包结构混乱。这里给出我当时整理的后端工程结构按业务模块分包而不是按技术层级分包com.example.prevent ├── common # 通用模块统一返回结果、异常处理、工具类 ├── config # 配置类CORS、拦截器、MyBatis-Plus配置、Swagger配置 ├── controller # 控制层按业务模块拆分如DiseaseReportController ├── service # 业务层接口实现类 ├── mapper # 数据访问层MyBatis-Plus的Mapper接口 ├── entity # 实体类与数据库表字段一一对应 ├── dto # 数据传输对象接收前端参数、返回前端数据 ├── vo # 视图对象如统计图表数据、看板数据 └── security # 认证授权JWT工具类、拦截器、登录逻辑dto和vo分开这一点值得强调。很多同学为了省事直接用实体类接收前端参数、再用实体类返回数据。小规模项目还行项目一复杂就出问题——前端传过来的密码字段不该返回到响应里多表联查的结果在实体类里根本放不下。dto负责接收vo负责返回各司其职代码会干净很多。2.3 前端工程目录与基础配置前端项目的结构按功能模块划分pages目录而不是按页面类型划分。这样做的原因是后期维护时找代码的方式跟使用系统的路径一致。我的前端目录组织大致如下src ├── api # 接口请求模块按后端Controller分文件 ├── assets # 静态资源 ├── components # 通用组件如Upload、Echarts、Pagination ├── layout # 布局组件侧边栏、顶栏、路由出口 ├── router # 路由配置包含动态路由和权限控制 ├── store # Vuex状态管理用户信息、菜单权限、token ├── utils # 工具类axios封装、时间格式化、数据导出 └── views # 业务页面按模块分文件夹路由的权限控制我放在router/index.js的全局前置守卫里每次路由跳转之前检查有没有token、刷新当前用户信息并动态追加路由。Vuex里存token和用户角色信息页面刷新时从localStorage恢复。这套方案逻辑简单对毕设来说足够稳定而且面试被问到怎么做路由级权限控制时你能讲清楚动态路由路由守卫状态持久化这条链路是个不错的加分项。3. 数据库设计与SQL脚本编写3.1 核心表结构的设计思路与字段细节数据库是这类系统的根基表设计不好后面全是坑。我从实际项目里把核心表挑出来逐一说设计思路。疾病防控系统的核心表大致有用户表sys_user、角色表sys_role、菜单权限表sys_menu、健康档案表health_record、疾病报告表disease_report、疫苗接种表vaccine_record、随访记录表follow_up_record、防控物资表material_info、物资出入库表material_stock_log、健康宣教表health_article、系统日志表sys_log。以疾病报告表为例字段设计不能只有主键和几个业务字段就完事。除了基本信息报告人、疾病类型、发病时间、诊断时间、上报时间还必须包含状态字段用于流转控制比如待审核、已审核、已驳回包含关联字段用于溯源比如关联的健康档案ID、关联的居民ID包含审核字段比如审核人、审核意见、审核时间。另外我建议所有业务表都带上create_time、update_time、deleted这三个字段。create_time和update_time交给MyBatis-Plus的自动填充功能deleted用于逻辑删除防止误删数据后无法恢复。健康档案表也是重点。它跟用户表是一对一关系除了姓名、性别、出生日期这些基础字段还应该有既往病史、过敏史、家族病史、慢性病情况、血型、身高体重、最近随访时间这些健康专项字段。注意这里如果直接用varchar存高血压、糖尿病这种逗号分隔的字符串后面做统计会很痛苦建议关联一个字典表或者用单独的关联表存多种既往病史。3.2 SQL脚本的写作规范与初始化数据SQL脚本不是随便把建表语句一扔就完事代码评审和答辩时老师真的会打开SQL文件看。我总结了几条实际经验每个表都要写注释。表名注释用CREATE TABLE后面的COMMENT字段注释每个字段都要写清楚。这样导入之后看表结构一目了然也方便前端同学对接字段含义。初始化数据是重点。有些同学只给表结构不给数据拿到源码跑起来后登录都登不进去因为用户表是空的。尽管SQL脚本中要包含一个默认管理员账号但注意密码存储必须用MD5或BCrypt加密后的密文不能出现明文密码。同时在sys_menu表里初始化菜单数据角色表初始化管理员和医护角色。外键约束能不放就不放。逻辑上维护关联关系物理上不加外键。加了外键之后删除数据、导入数据的顺序都得严格遵守否则经常报外键冲突错误。这是行业惯例答辩时也能解释得通。字符集和排序规则统一用utf8mb4和utf8mb4_general_ci别问为什么问了就是emoji表情和生僻字会教做人。字段类型的选择上id用bigint自增金额和数量用decimal时间一律datetime状态用tinyint或int加注释文本用varchar大段内容用text。3.3 MyBatis-Plus配合SQL脚本的落地细节既然用了MyBatis-Plus实体类里的注解建议直接写好TableName指定表名TableId指定主键策略为AUTOTableLogic标记逻辑删除字段TableField(fill FieldFill.INSERT)标记自动填充字段。这一步做完了后面写service层时会省非常多的时间。数据库连接配置要提醒一点。spring.datasource.url里要带serverTimezoneAsia/Shanghai和useUnicodetruecharacterEncodingutf8否则高版本MySQL驱动下很容易出现时区报错。驱动版本和MySQL版本要对应mysql-connector-java 8.x对应MySQL 5.7和8.0都可以但配置driver-class-name要用com.mysql.cj.jdbc.Driver新旧写法不一样。4. 后端接口开发与接口文档规范4.1 接口设计规范与统一返回格式接口设计上我推荐全部走RESTful风格。资源用名词复数操作用HTTP动词GET做查询、POST做新增、PUT做修改、DELETE做删除。路径命名统一小写中划线风格比如/api/health-record、/api/vaccine-record/page。这样一套下来接口文档不用写太多废话前端能大致猜到路径规律。统一返回格式是必做的。所有接口的返回结构一致前端Axios封装才好做统一处理。我项目里定义了一个Result类结构如下{ code: 200, message: 操作成功, data: {} }code为200表示成功401表示未登录或token失效500表示服务器异常。业务失败用自定义code区分比如疾病报告审核时如果状态不对返回4001。分页查询返回的数据结构也统一recordList列表数据、total总记录数、current当前页码、size每页大小。前端拿到这个结构直接往表格组件里塞不需要再做适配。4.2 接口文档应该写成什么样接口文档太重要了重要到值得单独拿出来说。很多项目源码里的接口文档就是复制粘贴的Swagger生成的HTML可读性极差。我的经验是Swagger在线调试可以要但一份手写的Markdown接口文档必须同步维护。每个接口包含以下几个部分接口地址如POST /api/disease-report/audit功能说明这个接口是干什么的、谁在用、什么场景下用请求参数表格字段名、类型、是否必填、说明响应结果示例JSON格式把关键字段的注释写在旁边错误码说明什么情况下会返回什么code在接口层用Swagger注解做好标注也很有必要。Api、ApiOperation、ApiImplicitParam这些注解写起来很快但生成出来的在线文档对前端同学联调非常友好尤其是需要快速查看接口参数含义时比翻代码高效得多。4.3 几个核心接口的实现要点挑几个有代表性的接口展开讲。登录接口。登录接口返回token前端把token存到localStorage后续所有请求在请求头里带上Authorization字段。后端写一个拦截器HandlerInterceptor统一拦截除登录、注册、验证码之外的接口从请求头解析token解析失败直接返回401。token用JWT生成密钥放在配置文件中过期时间建议12小时。这里要特别处理token过期和用户被禁用两种情况返回的提示信息不能只写未登录要有区分度。疾病报告审核接口。这个接口核心是状态的流转判断不是简单的update。审核操作发生时前端会传报告ID和审核结果通过/驳回以及审核意见。后端要把状态流转的合法性校验做起来——已经审核过的报告不能重复审核被驳回的报告不能直接变为已通过。这个校验逻辑写在service层虽然代码不多但体现的是业务严谨性答辩时讲出来是亮点。数据统计接口。做ECharts图表的接口返回的数据结构要适配前端图表组件。比如按月统计疾病报告数量的接口返回两种格式的数据categories月份列表和values数量列表。前端拿到直接作为x轴和y轴数据。这里SQL要掌握好date_format函数和group by的配合使用统计类SQL写不好会出一个大坑——查出来的月份排序乱、缺失月份不补零。我采用的方案是先查出统计周期内的所有月份列表再用左连接补全数据。5. 前端Vue页面实现与核心交互5.1 登录页与主布局的搭建思路登录页是整个系统给人的第一印象但毕设阶段不建议花过多时间设计炫酷动效。一张居中卡片左侧品牌区右侧登录表单配上验证码功能干净整洁就够用。验证码我建议做一个基于Canvas的前端验证码或者用后端生成图片返回给前端把验证码是谁生成的、怎么校验的讲清楚这也是答辩的高频问题。主布局采用经典的左侧菜单加右侧内容区。侧边栏菜单根据当前登录用户的角色动态渲染后端登录成功后返回该用户的菜单列表前端根据菜单列表动态生成侧边栏和路由而不是在前端代码里写死。这一点非常关键因为管理员看到的是系统管理菜单普通用户不应该看到。做动态菜单涉及Vue Router的addRoutes方法、Vuex里存菜单数据、刷新页面后重新拉取菜单这几个环节建议提前把链路走通。5.2 核心业务页面怎么实现更靠谱疾病报告审核页和健康档案管理页是系统里最核心的两个页面。这类页面的通用结构是搜索条件区域 表格区域 分页控件 弹窗表单。搜索条件至少要有时间范围、疾病类型、报告状态三个维度对应后端接口的查询条件参数。表格的每一行操作列包含详情、编辑、删除以及根据状态动态显示的操作按钮——待审核时出现审核按钮已审核时置灰。重点说一个细节表格里的状态字段后端返回给前端的一定是状态码如0、1、2前端页面显示中文。这里的映射逻辑要放在前端统一的字典文件里或者在表格渲染时用formatter函数转换。不要存在页面里写死三元表达式的情况因为疾病类型、审核状态这类字典枚举在多个页面都会用统一管理才能保证改一处全部生效。疫苗预约流程是一个多步骤交互的体现。用户选择疫苗类型、选择接种日期、提交预约后端创建预约记录同时扣减疫苗库存。注意这里扣库存和创建预约要在同一个事务里完成否则会出现预约成功但库存扣减失败的数据不一致问题。5.3 ECharts统计图表与数据大屏页统计图表是毕设最能出效果的部分也是体现工作量最直观的地方。我做了三个核心图表近三个月疾病报告趋势折线图、疾病类型占比饼图、防控物资库存预警的横向柱状图。ECharts的引入方式推荐按需引入不要整个全量包引入打包体积会差一倍。图表数据对接后端统计接口前端只需要把接口返回的categories和values填到option里。如果想让系统更有亮点可以做一个简易的数据看板首页。顶部放四个统计卡片今日新增报告、累计健康档案数、本月疫苗接种数、库存预警数中间放趋势图和饼图。这些数据全部走后端统计接口前端用ECharts渲染。看板页在答辩演示时非常加分因为一眼看过去有系统平台的量级感。6. 环境配置与打包部署6.1 本地开发环境的版本搭配建议环境搭不对一半的报错都源于版本冲突。我给出一套经过实测的版本组合照抄即可JDK 1.8或11、Maven 3.6.3、MySQL 5.7或8.0、Node.js 14或16、SpringBoot 2.7.x、Vue CLI 4.x或5.x。SpringBoot版本这块现在很多同学踩坑3.x版本要求JDK17如果环境是JDK8不要硬上SpringBoot 3.x。同理MyBatis-Plus和SpringBoot 2.7.x搭配使用3.5.x版本线上方案非常成熟。6.2 前后端分离项目的部署发布流程后端打包用Maven的package命令生成jar包后通过java -jar启动。注意打包之前要确认application.yml里的数据库地址、账号密码是生产环境的不要本地库密码发布了上去。前端打包用npm run build生成dist目录。部署方式有两种选择一种是前后端完全分离部署后端跑在服务器8080端口前端dist目录用Nginx托管Nginx配置反向代理把/api路径转发到后端服务另一种是把前端打包后的文件放进后端src/main/resources/static目录打成一个大jar包直接java -jar跑。毕设演示场景推荐第二种部署简单一个jar包搞定一切拷到哪都能跑。不过我实际更推荐第一种因为Nginx反向代理的配置过程本身就是面试和答辩的加分项而且前后端分离部署更符合生产实践。6.3 打包过程中常见的坑Vue打包后请求后端接口的地址问题排在第一位。本地开发时前端地址是localhost:8080后端接口是localhost:8081跨域通过后端CORS配置解决。但打包上线之后前端页面的域名变成Nginx的地址请求后端如果走相对路径或者写死的localhost就会出问题。我的做法是把接口基础路径写在.env.production文件里后端上线后baseURL指向Nginx的反向代理地址/api这样页面里所有请求都走/api前缀由Nginx统一转发。还有一个坑是history路由模式刷新404。Vue Router默认hash模式地址栏带#号刷新没问题。如果切换到history模式地址栏干净好看Nginx需要配置try_files规则否则在非首页路由刷新时就会404。怕麻烦就保持hash模式我实际推荐hash模式用于毕设演示省心稳定。7. 常见问题与排查经验实录7.1 接口报跨域错误的排查思路跨域是前后端分离项目里出现频率最高的问题。先分清楚是开发环境跨域还是生产环境跨域。开发环境跨域问题在后端配置一个CorsFilter就可以解决。注意allowedOrigins不要写成*这样跟allowCredentials(true)会冲突浏览器会直接拦截。生产环境的跨域通过Nginx反代解决让前端请求同源的/api路径由Nginx转发到后端从根源上规避跨域。排查跨域问题有个技巧打开浏览器F12看Network面板如果请求的状态是failed但后端日志显示已经收到了请求那就是跨域拦截在浏览器端如果后端日志完全没有请求记录说明请求根本没到达后端是代理配置有问题。7.2 MyBatis-Plus分页查不出数据分页查不出数据这个坑非常经典。MyBatis-Plus从3.5.x版本开始分页插件需要单独配置不配置的话分页查询直接失效返回total为0或者返回全部数据。很多所谓的项目源码里都没有配置PaginationInterceptor拿到手里一跑分页就出问题。我在config包下专门写了一个MybatisPlusConfig把MybatisPlusInterceptor作为Bean注册进去再添加PaginationInnerInterceptor这样分页才正常。顺带一提联表查询的分页total是会自动查的但如果SQL里有多对一关系还需要关注count查询的正确性。7.3 前端打包后接口404或无法登录这类问题的排查顺序是先看浏览器F12的Network请求接口请求是否发出、状态码多少再看后端日志请求是否到达、报什么异常最后看数据库是否SQL执行失败。我遇到过一次打包后无法登录的情况排查下来发现是后端拦截器放行的路径配置里只放行了登录接口但验证码接口被拦截了导致前端一直提示验证码错误。所以拦截器的放行路径一定要梳理清楚放行接口包括登录、验证码、健康资讯公开查询其他全部需要token。7.4 我的一些补充建议这套系统的边界可以根据需要扩。如果学有余力建议在现有基础上加一个使用Redis的模块——比如登录验证码存储、数据看板缓存把缓存讲清楚是加分项。前端方面有精力可以把数据看板做成大屏样式用dataV之类的组件库增强视觉效果。做毕设项目的核心目标不是代码量多而是每个模块都要能自圆其说被问到为什么这么设计时能讲出逻辑。你在项目里留下的每一个选择最好都对应一个可以讲清楚的理由。哪怕是为什么用MyBatis-Plus而不用JPA这种基础问题提前准备好答案答辩时会从容很多。最后再分享一个实际体会把这个系统完整跑通之后我强烈建议你用Docker把MySQL、后端、前端分别打一个镜像写一个docker-compose.yml一键启动。这个操作难度不大但能学到的云原生部署知识对后续找工作或深造都有直接帮助也会让这个毕设项目的完成度真正达到行业项目的体量。