尧图网页设计 
我手里这套SpringBootVue搭建的疾病防控综合系统平台是整理好的一套Java Web毕设项目代码之外同时配了SQL脚本和接口文档。很多同学拿到这种源码包第一反应是赶紧启动结果往往被数据库、端口、依赖版本轮番折磨一下午。今天这篇我就把这套“源码脚本文档”的项目底细完整盘一遍顺带讲讲怎么用它交付一个能答辩、能演示、能写论文的毕设。这套系统适合的人群很明确正在做Java Web方向毕业设计、又不想从零设计所有功能的同学或者已经有一套模板但不知道怎么讲清楚项目亮点的同学。它不是那种只拿得出手的“花架子”而是把疾控业务里最常见的病例上报、审核、密接随访、物资出入库、数据统计都串起来了。你拿到之后可以本地跑通也能按自己的需求改模块、换页面。我建议你先别急着敲启动命令跟着下面的思路把项目从业务到代码过一遍这样后面不管是改功能、写论文还是答辩提问都会从容很多。1. 拿到这套源码先别急着跑先把系统功能闭环理顺毕设和真正的商业系统有个本质区别商业系统追求稳定和复杂权限毕设项目追求“能讲清楚一个完整业务闭环”。疾病防控综合平台听起来范围很大但落到代码上核心就是一件事让异常情况从被发现、被处置、被跟踪到最终统计分析所有环节都有据可查。1.1 疾病防控综合平台到底解决什么问题这类系统通常面向疾控中心、学校、社区或园区管理方。日常工作中最麻烦的不是某个单点登记而是跨部门、跨流程的信息同步。比如基层网格员发现一个传染病疑似病例要先填表上报疾控管理员审核确认后转为正式病例接着还要安排密接人员排查、健康随访、疫苗接种记录最后月底要出一份统计报表。如果没有一个平台这些数据散落在Excel、微信、纸质表里既容易漏也难追溯。所以这套SpringBootVue项目在设计上把业务拆成了几个大模块系统管理、病例上报、病例审核、密接管理、健康随访、疫苗接种、物资管理、公告通知和数据统计。每个模块看起来都不复杂但连起来就是一条完整链条发现登记 - 审核确认 - 跟踪随访 - 物资保障 - 数据汇总。做毕设时不要被“疾病防控”这四个字吓到。你用不着真正实现医院级别的传染病直报系统只要把一条核心业务线做通、做扎实再配上常规的权限控制和前端页面就已经达到毕业设计的深度要求了。1.2 三个角色和一套审批流转逻辑这套系统里最常见的角色划分有三种超级管理员、疾控管理员、基层网格员或普通用户。超级管理员负责系统基础配置、用户分配、角色授权、数据字典维护。疾控管理员负责病例审核、密接任务分派、物资出入库审批、查看统计报表。基层网格员/普通用户负责发现异常后登记上报、填写每日健康随访、查看通知公告。权限设计上后端通过Spring Security JWT做接口级权限控制前端通过路由守卫和按钮级指令控制页面显示。你不能让普通用户看到“病例审核”按钮也不能让网格员调删除接口。这些在论文里可以重点展开尤其适合放在“系统设计”章节。业务流转可以用一句话概括普通用户提交上报单管理员审核通过后形成正式病例记录同时自动创建密接登记任务和随访提醒每天由网格员补充跟踪信息最后病例状态从“待审核”走到“随访中”再走到“已结案”。整个流程只要有一个环节没做系统的完整性就会打折扣。1.3 源码、SQL脚本、接口文档三件套怎么配合这个标题里写了完整项目源码加SQL脚本加接口文档很多人不知道怎么用这三样东西。源码一般包含两个工程一个SpringBoot后端一个Vue前端。SQL脚本负责把数据库表结构和初始化数据一次性建好避免你手动建表建到崩溃。接口文档则把后端暴露的每个接口列清楚包括请求地址、请求方式、参数、返回结构。它的作用是让你不翻后端代码也能知道怎么调接口。我第一次拿到这种三件套时习惯顺序是先导入SQL脚本把库表和测试账号准备好再启动后端打开Swagger接口文档挨个接口试一遍最后启动前端用页面去操作完整流程。如果一上来就跑前端大概率会因为后端没跑起来而看到满屏报错。记住这个顺序后面对照源码看逻辑时会更顺。2. 打开SQL脚本之前先看懂表与表之间的业务账本数据库设计是毕设答辩老师重点看的东西。很多同学拿到SQL脚本后直接执行能跑通就再也不看了结果被问“这张表为什么这么设计”时支支吾吾。想避免这种情况就得先把脚本里的核心表当成一张业务账本去读。2.1 核心表设计从用户到病例从物资到统计这套系统的SQL脚本里一般会包含十几张表。我整理了一下最常见的组合表名作用核心字段思路sys_user用户表用户名、密码、姓名、手机号、部门、状态sys_role角色表角色编码、角色名称sys_user_role用户角色关联表用户与角色的多对多关系sys_menu菜单权限表菜单名称、父级ID、路由地址、权限标识dz_case病例信息表病例编号、姓名、证件号、疾病类型、上报时间、状态dz_report上报记录表上报人、上报内容、上报时间、审核状态dz_contact密接人员表关联病例、姓名、联系方式、跟踪状态dz_follow随访记录表关联病例/密接、体温、症状、随访时间、随访人dz_vaccine疫苗接种记录表接种人、疫苗名称、剂次、接种时间dz_material防控物资表物资名称、分类、库存、预警库存、单位dz_material_log物资出入库日志表出入库类型、数量、操作人、操作时间dz_notice公告通知表标题、内容、发布人、发布时间病例表是整个系统的核心。它除了基础的人员信息外一定要有case_no唯一编号、disease_type疾病类型、report_time上报时间、status状态字段。状态字段建议用0待审核、1已审核、2随访中、3已结案这类整数枚举前端再映射成中文标签比直接存字符串更规范。密接表和随访表是一对多的关系一个病例可以对应多个密接人员一个密接人员又可以有多条随访记录。你不需要在密接表里反复存病例的全部信息只存一个case_id外键去关联病例表就行。2.2 字段设计里那些决定成败的小细节执行SQL脚本之前我建议你先看看建表语句里有没有这几点如果没有自己加上也不难。第一字符集必须用utf8mb4。utf8mb4和utf8的区别在于前者能存四字节的emoji和生僻字而且MySQL 8.0默认就是utf8mb4。如果脚本里写着DEFAULT CHARSETutf8遇到特殊字符时可能出现数据截断或乱码。第二主键统一用bigint自增或者雪花ID。不要用int也不要为了省事把主键设计成varchar。如果你的接口直接返回主键给前端还要注意后端的Long类型可能会在前端精度丢失这个坑后面专门说。第三尽量用逻辑外键不要用物理外键。也就是说dz_contact.case_id在表结构上没有真正的FOREIGN KEY约束而是在SQL查询里用JOIN把它们关联起来。原因很实际物理外键在删除、更新时容易触发连锁约束问题而且毕设阶段经常要造测试数据逻辑外键改起来更灵活。第四每张表都建议带create_time、update_time、deleted三个字段。deleted用来做逻辑删除配合MyBatis-Plus的TableLogic业务上删除记录时只改成1查询时自动过滤。答辩时问到“怎么防止误删”这招很好使。第五索引不要乱加但要给常用查询字段加索引。比如dz_case表的status、report_time、case_no统计报表要按时间分组审核列表要按状态过滤没有索引的话数据量稍微大一点查询就慢。2.3 初始化数据与执行SQL脚本的正确姿势SQL脚本的价值在于一次把库建好同时把测试数据准备好。执行方法其实就两种。如果你习惯命令行可以这样操作mysql -u root -p source /path/to/disease.sql;也可以直接在命令行里执行mysql -u root -p disease disease.sql前提是你已经创建好了disease这个数据库或者脚本开头自带CREATE DATABASE IF NOT EXISTS disease。用Navicat之类可视化工具的同学直接打开SQL文件然后运行注意脚本里的注释不要选错更不要把它执行到别的库里。执行完脚本之后第一件事不是启动后端而是查一下初始化数据。比如执行SELECT * FROM sys_user;你会看到管理员账号的密码不是123456而是一长串$2a$10$开头的BCrypt哈希值。这是正常的因为后端登录逻辑用的是BCryptPasswordEncoder校验密码。千万别试图在SQL里改密码字段要改密码得用后端代码跑一段加密工具类或者注册接口造一个用户。初始化数据里通常还会带角色菜单、字典数据和几条演示病例。演示病例的时间尽量分布在不同月份这样统计大屏按时间分组时才有曲线效果。如果脚本里的测试数据太少我都是自己在管理后台再录入一批避免演示时图表太难看。3. SpringBoot后端分层结构、登录认证与接口文档规范后端是整个项目的发动机。SpringBoot框架的优点就是约定大于配置、内嵌Tomcat、生态成熟特别适合Java Web毕设。我见过太多人把代码全堆在Controller里一个接口几百行这种代码虽然能跑但论文里根本没法写“系统设计”。所以这一章重点说分层和规范。3.1 后端工程结构怎么组织答辩老师才会觉得你“懂行”标准的SpringBoot后端工程包名建议按照com.xxx.disease来组织。里面核心分包如下disease-backend ├── src/main/java/com/xxx/disease │ ├── DiseaseApplication.java │ ├── common/ │ │ ├── Result.java │ │ ├── PageResult.java │ │ └── BusinessException.java │ ├── config/ │ │ ├── SecurityConfig.java │ │ ├── CorsConfig.java │ │ ├── Knife4jConfig.java │ │ └── MybatisPlusConfig.java │ ├── controller/ │ │ ├── AuthController.java │ │ ├── CaseController.java │ │ ├── FollowController.java │ │ └── MaterialController.java │ ├── entity/ │ │ ├── Case.java │ │ ├── User.java │ │ └── Material.java │ ├── mapper/ │ │ ├── CaseMapper.java │ │ └── UserMapper.java │ ├── service/ │ │ ├── CaseService.java │ │ └── UserService.java │ ├── security/ │ │ ├── JwtAuthenticationFilter.java │ │ ├── LoginUser.java │ │ └── JwtUtil.java │ └── utils/ │ ├── ExcelUtil.java │ └── IdUtil.java └── src/main/resources/ ├── application.yml ├── mapper/ │ └── CaseMapper.xml └── banner.txt这套结构最核心的思想是分层Controller只负责接收参数和返回结果Service里写业务逻辑Mapper负责和数据库打交道。答辩老师问你“为什么这么分”你可以回答为了降低耦合、方便测试、以后扩展新功能时不用动老代码。后端ORM框架建议用MyBatis-Plus而不是纯MyBatis。MyBatis-Plus内置了单表CRUD方法不用为每张表写繁琐的XML写毕设能省很多时间。如果你的SQL脚本里用了逻辑删除字段只需要在实体类deleted字段上加TableLogic再在配置里声明全局逻辑删除配置即可。3.2 JWT Spring Security的登录认证链路登录认证是Java Web毕设里最容易被问到的点。这套系统用的是JWT令牌结合Spring Security框架。它的流程可以理解为第一次登录时用用户名密码换一张“通行证”之后每次请求都带着通行证后端检查通行证是否有效不再像Session那样在服务器内存里保存会话状态。后端核心逻辑大致是这样的接收前端传来的用户名和密码调用UserDetailsService加载用户信息用BCryptPasswordEncoder.matches校验密码校验通过后用JwtUtil生成一个包含用户ID、用户名、角色信息的Token前端把这个Token存到localStorage后续请求放在Authorization请求头里JWT工具类里一般有两个方法public String generateToken(Long userId, String username, ListString roles) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .claim(roles, roles) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token) .getBody(); }SecurityConfig里需要把登录接口、Swagger文档路径、静态资源路径放行其他接口全部要求认证。一般这样配置http.authorizeRequests() .antMatchers(/api/auth/login, /doc.html, /webjars/**, /v3/api-docs/**).permitAll() .antMatchers(/api/cases/audit/**).hasRole(ADMIN) .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class);JWT的优点是后端无状态、水平扩展方便、适合前后端分离缺点也很明显Token一旦签发在过期前很难主动吊销。答辩时如果老师问这个你如实说优缺点就行不用慌。3.3 统一返回体、全局异常与接口文档的规范化前后端分离项目最怕响应格式不统一。有的接口返回{code:200}有的接口返回{success:true}前端会对接得很痛苦。这套项目里我强烈建议所有接口统一走Result返回体public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.setCode(200); r.setMessage(操作成功); r.setData(data); return r; } public static T ResultT error(Integer code, String message) { ResultT r new Result(); r.setCode(code); r.setMessage(message); return r; } }分页接口再包一层PageResult包含records、total、current、size四个字段。前端拿到后可以直接渲染表格和分页器。全局异常用RestControllerAdvice处理这样代码里不用到处写try-catch。业务异常统一抛出BusinessException参数校验失败、登录失效、权限不足分别对应不同错误码前端拦截器根据code决定是弹提示还是跳转登录页。接口文档方面SpringBoot项目常用Knife4j增强Swagger访问地址一般是http://localhost:8080/doc.html。Controller的方法上加ApiOperation描述接口用途参数类上加ApiModelProperty说明字段含义。接口文档不只是给前端看的也是你自己写论文时“系统实现”章节的重要素材。接口路径请求方式功能说明是否需要登录/api/auth/loginPOST登录并返回Token否/api/cases/pageGET分页查询病例列表是/api/casesPOST新增病例上报是/api/cases/auditPUT审核病例是/api/followsPOST新增随访记录是/api/material/in-outPOST物资出入库是/api/stats/case-trendGET按时间统计病例趋势是接口设计时注意遵循RESTful风格查询用GET新增用POST修改用PUT删除用DELETE。路径里能用名词就不用动词能表达资源就尽量表达资源。3.4 病例上报到审核这条核心链路的事务处理单表增删改查没有难度难的是“上报一个病例同时要自动生成密接排查任务”这种跨表操作。这里必须加事务否则上报成功但密接任务创建失败数据就不一致了。Service层可以这样写Transactional(rollbackFor Exception.class) public Long createCaseAndContact(CaseDTO dto) { CaseEntity caseEntity new CaseEntity(); BeanUtils.copyProperties(dto, caseEntity); caseEntity.setStatus(0); // 待审核 caseMapper.insert(caseEntity); // 根据上报信息生成首条密接任务 ContactEntity contact new ContactEntity(); contact.setCaseId(caseEntity.getId()); contact.setContactName(dto.getReportUserName()); contact.setStatus(0); contactMapper.insert(contact); return caseEntity.getId(); }Transactional保证了insert case和insert contact要么都成功要么都回滚。答辩时如果老师问“多个表操作时怎么保证数据一致性”这就是标准答案。参数校验方面建议用Valid配合DTO不要直接在Controller里接收HttpServletRequest然后手动取值。比如病例上报时姓名、联系电话、疾病类型不能为空手机号要符合正则。校验规则写在DTO上代码会比在业务方法里写一串if干净很多。4. Vue前端路由、请求封装与页面落地的关键细节后端接口做得再规范最终还是要靠Vue页面把功能呈现出来。这个前端部分我从工程结构说到接口联调尽量把毕设里真正会用到的东西讲透。4.1 前端工程与依赖环境Vue工程一般叫disease-frontend用Vue CLI或Vite创建。考虑到很多学校的毕设环境还是Vue 2 Element UI如果你拿到的是Vue 3 Element Plus版本也不影响核心逻辑一致。我只是建议别为了追新随意升级课件里教的版本往往最稳妥。前端目录大致是这样disease-frontend ├── public/ ├── src/ │ ├── api/ │ │ ├── auth.js │ │ ├── case.js │ │ └── stats.js │ ├── assets/ │ ├── components/ │ │ ├── CaseDetailDialog.vue │ │ └── StatusTag.vue │ ├── layout/ │ │ └── Index.vue │ ├── router/ │ │ └── index.js │ ├── store/ │ │ └── user.js │ ├── utils/ │ │ └── request.js │ └── views/ │ ├── Login.vue │ ├── dashboard/Index.vue │ ├── case/List.vue │ ├── follow/List.vue │ ├── material/List.vue │ └── system/UserList.vue ├── package.json └── vue.config.js组件化的意义在于复用。病例详情、状态标签、审核弹窗这些组件会在多个页面出现抽出来之后页面代码会瘦很多。4.2 axios封装、Token注入和路由守卫Vue前端和SpringBoot后端通信几乎都用axios。我习惯先封装一个request.js统一处理请求头、响应码和错误提示。import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { if (res.code 401) { localStorage.removeItem(token) router.push(/login) } else { Message.error(res.message || 请求失败) } return Promise.reject(new Error(res.message)) } return res }, error { Message.error(网络异常) return Promise.reject(error) } ) export default service写好了请求封装还需要在Vue Router的全局守卫里拦截未登录用户router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path ! /login !token) { next(/login) } else { next() } })这套组合拳做完登录状态管理就串起来了页面刷新时不会丢登录态Token过期时自动跳回登录页。动态路由方面如果你的菜单表里存了路由信息可以在登录后根据角色返回的菜单数组动态添加路由如果觉得麻烦也可以在前端写死路由再用v-if控制菜单显示。两种方式都能通过答辩动态路由加分更多但工作量也更大。4.3 核心页面怎么实现从上报到审核的交互逻辑登录页做完后最重要的就是病例管理相关页面。列表页的套路基本一致顶部放搜索条件疾病类型、状态、上报时间段中间放操作按钮新增、导出、审核、详情主体是el-table列表状态列用el-tag显示不同颜色底部放分页器新增病例的上报表单要特别注意疾病类型、病例编号、上报人、上报时间这些字段。病例编号可以交给后端生成上报人从当前登录用户的Token信息里解析前端不用让用户填。审核按钮只有在当前用户有权限且病例状态为“待审核”时才显示。如果页面比较多建议把“病例详情”抽成公共组件点击详情时弹出一个抽屉展示病例基本信息、密接列表、随访记录三个Tab页。这块做出来论文里的“系统实现”部分能配好几张图。统计大屏页面建议用ECharts。后端提供按时间分组统计接口前端拿到[{date: 2025-05-01, count: 12}, ...]这种格式后可以画折线图或柱状图。再加一个按疾病类型分组的饼图页面的视觉完整度就上来了。4.4 前后端联调最容易踩的四个坑第一跨域问题。前端开发服务器默认跑在localhost:8081后端跑在8080直接请求会跨域。最简单的办法是在vue.config.js里配代理module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样前端请求/api/xxx时开发服务器会转发到后端浏览器看起来就是同源请求。后端也要配一下CORS防止其他场景下跨域。第二Long类型精度丢失。后端主键是Long类型前端JavaScript的Number类型无法精确表示超过2^53的大整数所以接口返回的id到了前端会变成123456789012345670这种近似值。解决方法是让后端把Long类型的ID序列化成字符串比如在字段上加JsonSerialize(using ToStringSerializer.class)或者在全局配置里统一处理。第三路由模式导致的刷新404。Vue Router用history模式时刷新非首页路径后端服务没有对应的GET接口会返回404。部署到Nginx可以用try_files兜底或者干脆用hash模式。开发阶段用hash模式更省事就是地址栏会有个#。第四请求封装里忘记带Token。很多同学发现登录后调接口还是401大概率就是axios拦截器没生效或者Token存的key名不一致。排查时打开浏览器开发者工具看请求头里有没有Authorization字段一目了然。5. 从源码到可演示成品环境配置、SQL执行与两种部署方式跑通本地环境只是第一步你最后要交付的是一个能给别人演示的项目。这一章我会把部署和演示过程中最常翻车的细节都拎出来说清楚。5.1 本地运行前的一次环境核对我遇到过太多次“源码在我这跑得好好的到你这怎么不行”的情况根因基本都是环境不一致。这套SpringBootVue项目建议的环境如下技术推荐版本说明JDK1.8 或 11大多数SpringBoot 2.x项目都能用Maven3.6 以上管理后端依赖MySQL5.7 或 8.0最好是8.0脚本兼容性更稳Node.js14 以上运行前端构建工具npm6 以上安装依赖IDEA2020 以后普通社区版也可以这里特别提醒一点如果源码里的SpringBoot版本太高比如3.x那么很多老教程里的javax包名要改成jakartaMyBatis-Plus也得换适配版本。做毕设不建议用最新版SpringBoot稳定压倒一切。springboot版本太高带来的依赖冲突排查起来往往比写代码还耗时。后端application.yml里的数据源配置是重点检查项。数据库名、用户名、密码只要有一个不对启动就会报错。模板一般是这样的server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/disease?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: root mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0如果IDEA里要临时改端口可以直接在application.yml里改server.port或者在Run/Debug Configurations的环境变量里配置SERVER_PORT不用改代码。这不是什么高深操作但演示前一定要确认端口没被别的程序占用。5.2 SQL脚本导入命令行和Navicat两个入口执行SQL脚本看起来简单但很多人跌倒在小细节上。命令行方式我上面已经写了这里补充几点容易踩的问题。第一如果你的SQL脚本里没有CREATE DATABASE语句导入前要先建库CREATE DATABASE IF NOT EXISTS disease DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;第二导入中文乱码时在命令行连接参数里加上--default-character-setutf8mb4或者用Navicat打开脚本后把脚本文件的编码转成UTF-8再执行。第三如果你用的是MySQL 8.0驱动要用com.mysql.cj.jdbc.Driver而不是老版的com.mysql.jdbc.Driver。这两者在旧项目里一直是个坑看到ClassNotFoundException时可以先检查这里。第四导入完成后顺手验证一下数据条数SELECT COUNT(*) FROM sys_user; SELECT COUNT(*) FROM dz_case;如果sys_user表里没有管理员账号后面登录页面永远登不进去别提多尴尬。脚本没执行完整时后端启动并不会报错只有业务操作时才会暴露问题。5.3 Vue打包放进SpringBoot还是Nginx部署前端部署这个话题热搜里总能看到“vue打包放进springboot中”确实是一条实用路径。一种方法是完全前后端分离用Nginx托管前端打包后的dist目录再把/api开头的请求反向代理到SpringBoot后端。这是生产环境的常规做法。另一种方法是把前端打包后的静态文件复制到SpringBoot的src/main/resources/static目录下然后重新打包后端。这样最后只有后端一个jar包双击就能启动前后端同一个端口非常适合答辩现场演示不用额外启动Nginx。第二种方式的具体操作前端先执行npm run build把生成的dist目录里的index.html和static、js、css等资源复制到后端resources/static下。需要注意打包后的index.html里引用的资源路径如果是/assets/xx.js那么后端SpringBoot的static目录要能匹配到这个路径通常把目录结构放对就行。如果用了Vue Router的history模式放到SpringBoot里刷新子路由会404。最省事的办法是改成hash模式或者在SpringBoot里写一个Controller把非接口请求转发到index.html。毕设演示我建议直接用hash模式稳定、少坑。5.4 演示现场防翻车清单参加过答辩或给老师演示的同学都懂演示环节是最容易紧张的。我整理了一份自己每次演示前都会过一遍的清单MySQL服务启动了吗Navicat能连上吗后端jar包或IDEA里的服务还在运行吗端口有没有被占数据库连接配置是不是演示机器的密码前端页面打开时浏览器地址是开发服务器还是已经放进了后端staticToken过期没有如果过期了重新登录一次再开始。演示数据够不够列表页和统计图表不能是空的。你可以提前准备一个“演示脚本”按顺序列出登录、新增病例、审核、添加随访、查看统计、物资出库这六步操作每一步用哪个账号、点哪个按钮、预期看到什么结果都写好。真正演示时照着走不仅不慌还会给老师一种“这项目很扎实”的感觉。6. 论文与答辩把源码讲成自己的项目代码能跑只是结果论文和答辩才是把你这份工作“讲出来”的过程。很多同学代码写得还行一写论文就开始从网上复制结果内容和自己的项目完全对不上。下面这些思路可以帮你把源码和论文统一起来。6.1 论文大纲怎么搭一篇标准的Java Web毕设论文结构通常是这样摘要写清楚用了SpringBoot、Vue、MySQL这些技术实现了一个疾病防控综合系统平台包含哪些模块达到了什么效果。绪论项目背景、研究意义、国内外现状。这个部分不需要长篇大论重点是引出你做这个系统的必要性。相关技术介绍SpringBoot框架、Vue框架、MyBatis-Plus、JWT、MySQL。写的时候强调你项目里用了哪些特性不要写一堆用不到的。系统分析需求分析、角色分析、功能需求、非功能需求。系统设计总体架构、功能模块设计、数据库设计、接口设计。系统实现每个核心模块怎么做的配页面截图和核心代码。系统测试功能测试用例、测试结果、性能测试说明。总结与展望。写论文时要画图。用例图、ER图、系统架构图、功能结构图最好自己画别直接截网图。ER图里的表名和字段一定要和SQL脚本里一致这是老师最容易发现“论文和项目脱节”的地方。6.2 高频答辩问题与回答思路下面是这套系统答辩时最常被问到的几个问题你可以提前准备问题1为什么选用SpringBootVue答SpringBoot简化了Spring配置内嵌Tomcat适合快速构建后端服务Vue作为前端框架采用组件化和双向数据绑定适合前后端分离开发。两者结合能提高开发效率也方便后期维护。问题2JWT相比Session有什么优缺点答JWT服务端不保存会话状态天然支持分布式扩展Token里可以携带用户基本信息减少数据库查询。缺点是Token过期前无法主动吊销所以需要设置合理的过期时间并在前端做好401拦截。问题3数据库为什么用逻辑外键不用物理外键答物理外键在批量导入、删除时容易产生约束冲突影响性能逻辑外键由应用层保证关联关系更灵活适合当前系统的数据特点和开发节奏。问题4怎么防止SQL注入答项目里使用MyBatisSQL语句统一采用#{}预编译参数不使用${}直接拼接。预编译时参数不会和SQL语句混在一起解析从机制上规避了SQL注入。问题5项目中遇到的最大难点是什么答比较典型的是Long类型主键传到前端后精度丢失、前后端跨域、多表操作的事务一致性问题。然后结合自己的排查过程说明怎么解决的。这个回答要真实不要编一个太宏大的难题。问题6如果并发量变大怎么办答现阶段数据量还不大通过分页查询、索引优化已经能满足性能要求。后续可以引入Redis缓存热点数据用消息队列削峰或者做读写分离。这个回答的姿态要客观毕设阶段不需要吹得太大。6.3 值得自己动手加的加分功能源码能跑是及格能加一两个自己写的功能才算加分。我建议你在这套系统上做几个小而实的扩展第一用ECharts做一个数据可视化大屏。疾控类项目很适合用地图、折线图、饼图展示病例趋势视觉效果强论文里也能多两张截图。第二增加Excel导入导出。病例列表、随访记录、物资台账都可以通过EasyExcel导出成Excel老师会觉得功能考虑得很全面。第三增加定时统计任务。用Spring Task每天凌晨自动统计前一天的上报数和随访数生成汇总数据体现自动化意识。第四给随访记录加文件上传。随访时可以上传图片附件后端用本地磁盘或OSS保存。这个功能涉及文件上传下载也是答辩时比较好讲的点。有一点必须提醒如果这套源码本来就是网上买的你千万不要直接原封不动交上去。花时间把几个页面的样式改一改把数据库表名前缀换成自己的把某个模块的业务逻辑调一调至少让代码里有自己写的东西。否则老师一问细节连自己都解释不清楚。说实话毕设源码我一向不建议直接交上去你能把这份源码真正“用”起来才有意义。我个人整理这套项目时体会最深的一环是把SQL脚本里的十几张表连起来画业务流程图画通之后后端接口怎么设计、前端页面该放哪些按钮就全顺了。你拿到源码后第一件事也别想着换肤改样式先把“上报—审核—随访—统计”这条链路走通再往上面加自己的东西。照着这个思路答辩时随便问到你哪个类、哪张表、哪个接口你都接得住。 SpringBoot+Vue疾病防控系统毕设项目源码解析
我手里这套SpringBootVue搭建的疾病防控综合系统平台是整理好的一套Java Web毕设项目代码之外同时配了SQL脚本和接口文档。很多同学拿到这种源码包第一反应是赶紧启动结果往往被数据库、端口、依赖版本轮番折磨一下午。今天这篇我就把这套“源码脚本文档”的项目底细完整盘一遍顺带讲讲怎么用它交付一个能答辩、能演示、能写论文的毕设。这套系统适合的人群很明确正在做Java Web方向毕业设计、又不想从零设计所有功能的同学或者已经有一套模板但不知道怎么讲清楚项目亮点的同学。它不是那种只拿得出手的“花架子”而是把疾控业务里最常见的病例上报、审核、密接随访、物资出入库、数据统计都串起来了。你拿到之后可以本地跑通也能按自己的需求改模块、换页面。我建议你先别急着敲启动命令跟着下面的思路把项目从业务到代码过一遍这样后面不管是改功能、写论文还是答辩提问都会从容很多。1. 拿到这套源码先别急着跑先把系统功能闭环理顺毕设和真正的商业系统有个本质区别商业系统追求稳定和复杂权限毕设项目追求“能讲清楚一个完整业务闭环”。疾病防控综合平台听起来范围很大但落到代码上核心就是一件事让异常情况从被发现、被处置、被跟踪到最终统计分析所有环节都有据可查。1.1 疾病防控综合平台到底解决什么问题这类系统通常面向疾控中心、学校、社区或园区管理方。日常工作中最麻烦的不是某个单点登记而是跨部门、跨流程的信息同步。比如基层网格员发现一个传染病疑似病例要先填表上报疾控管理员审核确认后转为正式病例接着还要安排密接人员排查、健康随访、疫苗接种记录最后月底要出一份统计报表。如果没有一个平台这些数据散落在Excel、微信、纸质表里既容易漏也难追溯。所以这套SpringBootVue项目在设计上把业务拆成了几个大模块系统管理、病例上报、病例审核、密接管理、健康随访、疫苗接种、物资管理、公告通知和数据统计。每个模块看起来都不复杂但连起来就是一条完整链条发现登记 - 审核确认 - 跟踪随访 - 物资保障 - 数据汇总。做毕设时不要被“疾病防控”这四个字吓到。你用不着真正实现医院级别的传染病直报系统只要把一条核心业务线做通、做扎实再配上常规的权限控制和前端页面就已经达到毕业设计的深度要求了。1.2 三个角色和一套审批流转逻辑这套系统里最常见的角色划分有三种超级管理员、疾控管理员、基层网格员或普通用户。超级管理员负责系统基础配置、用户分配、角色授权、数据字典维护。疾控管理员负责病例审核、密接任务分派、物资出入库审批、查看统计报表。基层网格员/普通用户负责发现异常后登记上报、填写每日健康随访、查看通知公告。权限设计上后端通过Spring Security JWT做接口级权限控制前端通过路由守卫和按钮级指令控制页面显示。你不能让普通用户看到“病例审核”按钮也不能让网格员调删除接口。这些在论文里可以重点展开尤其适合放在“系统设计”章节。业务流转可以用一句话概括普通用户提交上报单管理员审核通过后形成正式病例记录同时自动创建密接登记任务和随访提醒每天由网格员补充跟踪信息最后病例状态从“待审核”走到“随访中”再走到“已结案”。整个流程只要有一个环节没做系统的完整性就会打折扣。1.3 源码、SQL脚本、接口文档三件套怎么配合这个标题里写了完整项目源码加SQL脚本加接口文档很多人不知道怎么用这三样东西。源码一般包含两个工程一个SpringBoot后端一个Vue前端。SQL脚本负责把数据库表结构和初始化数据一次性建好避免你手动建表建到崩溃。接口文档则把后端暴露的每个接口列清楚包括请求地址、请求方式、参数、返回结构。它的作用是让你不翻后端代码也能知道怎么调接口。我第一次拿到这种三件套时习惯顺序是先导入SQL脚本把库表和测试账号准备好再启动后端打开Swagger接口文档挨个接口试一遍最后启动前端用页面去操作完整流程。如果一上来就跑前端大概率会因为后端没跑起来而看到满屏报错。记住这个顺序后面对照源码看逻辑时会更顺。2. 打开SQL脚本之前先看懂表与表之间的业务账本数据库设计是毕设答辩老师重点看的东西。很多同学拿到SQL脚本后直接执行能跑通就再也不看了结果被问“这张表为什么这么设计”时支支吾吾。想避免这种情况就得先把脚本里的核心表当成一张业务账本去读。2.1 核心表设计从用户到病例从物资到统计这套系统的SQL脚本里一般会包含十几张表。我整理了一下最常见的组合表名作用核心字段思路sys_user用户表用户名、密码、姓名、手机号、部门、状态sys_role角色表角色编码、角色名称sys_user_role用户角色关联表用户与角色的多对多关系sys_menu菜单权限表菜单名称、父级ID、路由地址、权限标识dz_case病例信息表病例编号、姓名、证件号、疾病类型、上报时间、状态dz_report上报记录表上报人、上报内容、上报时间、审核状态dz_contact密接人员表关联病例、姓名、联系方式、跟踪状态dz_follow随访记录表关联病例/密接、体温、症状、随访时间、随访人dz_vaccine疫苗接种记录表接种人、疫苗名称、剂次、接种时间dz_material防控物资表物资名称、分类、库存、预警库存、单位dz_material_log物资出入库日志表出入库类型、数量、操作人、操作时间dz_notice公告通知表标题、内容、发布人、发布时间病例表是整个系统的核心。它除了基础的人员信息外一定要有case_no唯一编号、disease_type疾病类型、report_time上报时间、status状态字段。状态字段建议用0待审核、1已审核、2随访中、3已结案这类整数枚举前端再映射成中文标签比直接存字符串更规范。密接表和随访表是一对多的关系一个病例可以对应多个密接人员一个密接人员又可以有多条随访记录。你不需要在密接表里反复存病例的全部信息只存一个case_id外键去关联病例表就行。2.2 字段设计里那些决定成败的小细节执行SQL脚本之前我建议你先看看建表语句里有没有这几点如果没有自己加上也不难。第一字符集必须用utf8mb4。utf8mb4和utf8的区别在于前者能存四字节的emoji和生僻字而且MySQL 8.0默认就是utf8mb4。如果脚本里写着DEFAULT CHARSETutf8遇到特殊字符时可能出现数据截断或乱码。第二主键统一用bigint自增或者雪花ID。不要用int也不要为了省事把主键设计成varchar。如果你的接口直接返回主键给前端还要注意后端的Long类型可能会在前端精度丢失这个坑后面专门说。第三尽量用逻辑外键不要用物理外键。也就是说dz_contact.case_id在表结构上没有真正的FOREIGN KEY约束而是在SQL查询里用JOIN把它们关联起来。原因很实际物理外键在删除、更新时容易触发连锁约束问题而且毕设阶段经常要造测试数据逻辑外键改起来更灵活。第四每张表都建议带create_time、update_time、deleted三个字段。deleted用来做逻辑删除配合MyBatis-Plus的TableLogic业务上删除记录时只改成1查询时自动过滤。答辩时问到“怎么防止误删”这招很好使。第五索引不要乱加但要给常用查询字段加索引。比如dz_case表的status、report_time、case_no统计报表要按时间分组审核列表要按状态过滤没有索引的话数据量稍微大一点查询就慢。2.3 初始化数据与执行SQL脚本的正确姿势SQL脚本的价值在于一次把库建好同时把测试数据准备好。执行方法其实就两种。如果你习惯命令行可以这样操作mysql -u root -p source /path/to/disease.sql;也可以直接在命令行里执行mysql -u root -p disease disease.sql前提是你已经创建好了disease这个数据库或者脚本开头自带CREATE DATABASE IF NOT EXISTS disease。用Navicat之类可视化工具的同学直接打开SQL文件然后运行注意脚本里的注释不要选错更不要把它执行到别的库里。执行完脚本之后第一件事不是启动后端而是查一下初始化数据。比如执行SELECT * FROM sys_user;你会看到管理员账号的密码不是123456而是一长串$2a$10$开头的BCrypt哈希值。这是正常的因为后端登录逻辑用的是BCryptPasswordEncoder校验密码。千万别试图在SQL里改密码字段要改密码得用后端代码跑一段加密工具类或者注册接口造一个用户。初始化数据里通常还会带角色菜单、字典数据和几条演示病例。演示病例的时间尽量分布在不同月份这样统计大屏按时间分组时才有曲线效果。如果脚本里的测试数据太少我都是自己在管理后台再录入一批避免演示时图表太难看。3. SpringBoot后端分层结构、登录认证与接口文档规范后端是整个项目的发动机。SpringBoot框架的优点就是约定大于配置、内嵌Tomcat、生态成熟特别适合Java Web毕设。我见过太多人把代码全堆在Controller里一个接口几百行这种代码虽然能跑但论文里根本没法写“系统设计”。所以这一章重点说分层和规范。3.1 后端工程结构怎么组织答辩老师才会觉得你“懂行”标准的SpringBoot后端工程包名建议按照com.xxx.disease来组织。里面核心分包如下disease-backend ├── src/main/java/com/xxx/disease │ ├── DiseaseApplication.java │ ├── common/ │ │ ├── Result.java │ │ ├── PageResult.java │ │ └── BusinessException.java │ ├── config/ │ │ ├── SecurityConfig.java │ │ ├── CorsConfig.java │ │ ├── Knife4jConfig.java │ │ └── MybatisPlusConfig.java │ ├── controller/ │ │ ├── AuthController.java │ │ ├── CaseController.java │ │ ├── FollowController.java │ │ └── MaterialController.java │ ├── entity/ │ │ ├── Case.java │ │ ├── User.java │ │ └── Material.java │ ├── mapper/ │ │ ├── CaseMapper.java │ │ └── UserMapper.java │ ├── service/ │ │ ├── CaseService.java │ │ └── UserService.java │ ├── security/ │ │ ├── JwtAuthenticationFilter.java │ │ ├── LoginUser.java │ │ └── JwtUtil.java │ └── utils/ │ ├── ExcelUtil.java │ └── IdUtil.java └── src/main/resources/ ├── application.yml ├── mapper/ │ └── CaseMapper.xml └── banner.txt这套结构最核心的思想是分层Controller只负责接收参数和返回结果Service里写业务逻辑Mapper负责和数据库打交道。答辩老师问你“为什么这么分”你可以回答为了降低耦合、方便测试、以后扩展新功能时不用动老代码。后端ORM框架建议用MyBatis-Plus而不是纯MyBatis。MyBatis-Plus内置了单表CRUD方法不用为每张表写繁琐的XML写毕设能省很多时间。如果你的SQL脚本里用了逻辑删除字段只需要在实体类deleted字段上加TableLogic再在配置里声明全局逻辑删除配置即可。3.2 JWT Spring Security的登录认证链路登录认证是Java Web毕设里最容易被问到的点。这套系统用的是JWT令牌结合Spring Security框架。它的流程可以理解为第一次登录时用用户名密码换一张“通行证”之后每次请求都带着通行证后端检查通行证是否有效不再像Session那样在服务器内存里保存会话状态。后端核心逻辑大致是这样的接收前端传来的用户名和密码调用UserDetailsService加载用户信息用BCryptPasswordEncoder.matches校验密码校验通过后用JwtUtil生成一个包含用户ID、用户名、角色信息的Token前端把这个Token存到localStorage后续请求放在Authorization请求头里JWT工具类里一般有两个方法public String generateToken(Long userId, String username, ListString roles) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .claim(roles, roles) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token) .getBody(); }SecurityConfig里需要把登录接口、Swagger文档路径、静态资源路径放行其他接口全部要求认证。一般这样配置http.authorizeRequests() .antMatchers(/api/auth/login, /doc.html, /webjars/**, /v3/api-docs/**).permitAll() .antMatchers(/api/cases/audit/**).hasRole(ADMIN) .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class);JWT的优点是后端无状态、水平扩展方便、适合前后端分离缺点也很明显Token一旦签发在过期前很难主动吊销。答辩时如果老师问这个你如实说优缺点就行不用慌。3.3 统一返回体、全局异常与接口文档的规范化前后端分离项目最怕响应格式不统一。有的接口返回{code:200}有的接口返回{success:true}前端会对接得很痛苦。这套项目里我强烈建议所有接口统一走Result返回体public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.setCode(200); r.setMessage(操作成功); r.setData(data); return r; } public static T ResultT error(Integer code, String message) { ResultT r new Result(); r.setCode(code); r.setMessage(message); return r; } }分页接口再包一层PageResult包含records、total、current、size四个字段。前端拿到后可以直接渲染表格和分页器。全局异常用RestControllerAdvice处理这样代码里不用到处写try-catch。业务异常统一抛出BusinessException参数校验失败、登录失效、权限不足分别对应不同错误码前端拦截器根据code决定是弹提示还是跳转登录页。接口文档方面SpringBoot项目常用Knife4j增强Swagger访问地址一般是http://localhost:8080/doc.html。Controller的方法上加ApiOperation描述接口用途参数类上加ApiModelProperty说明字段含义。接口文档不只是给前端看的也是你自己写论文时“系统实现”章节的重要素材。接口路径请求方式功能说明是否需要登录/api/auth/loginPOST登录并返回Token否/api/cases/pageGET分页查询病例列表是/api/casesPOST新增病例上报是/api/cases/auditPUT审核病例是/api/followsPOST新增随访记录是/api/material/in-outPOST物资出入库是/api/stats/case-trendGET按时间统计病例趋势是接口设计时注意遵循RESTful风格查询用GET新增用POST修改用PUT删除用DELETE。路径里能用名词就不用动词能表达资源就尽量表达资源。3.4 病例上报到审核这条核心链路的事务处理单表增删改查没有难度难的是“上报一个病例同时要自动生成密接排查任务”这种跨表操作。这里必须加事务否则上报成功但密接任务创建失败数据就不一致了。Service层可以这样写Transactional(rollbackFor Exception.class) public Long createCaseAndContact(CaseDTO dto) { CaseEntity caseEntity new CaseEntity(); BeanUtils.copyProperties(dto, caseEntity); caseEntity.setStatus(0); // 待审核 caseMapper.insert(caseEntity); // 根据上报信息生成首条密接任务 ContactEntity contact new ContactEntity(); contact.setCaseId(caseEntity.getId()); contact.setContactName(dto.getReportUserName()); contact.setStatus(0); contactMapper.insert(contact); return caseEntity.getId(); }Transactional保证了insert case和insert contact要么都成功要么都回滚。答辩时如果老师问“多个表操作时怎么保证数据一致性”这就是标准答案。参数校验方面建议用Valid配合DTO不要直接在Controller里接收HttpServletRequest然后手动取值。比如病例上报时姓名、联系电话、疾病类型不能为空手机号要符合正则。校验规则写在DTO上代码会比在业务方法里写一串if干净很多。4. Vue前端路由、请求封装与页面落地的关键细节后端接口做得再规范最终还是要靠Vue页面把功能呈现出来。这个前端部分我从工程结构说到接口联调尽量把毕设里真正会用到的东西讲透。4.1 前端工程与依赖环境Vue工程一般叫disease-frontend用Vue CLI或Vite创建。考虑到很多学校的毕设环境还是Vue 2 Element UI如果你拿到的是Vue 3 Element Plus版本也不影响核心逻辑一致。我只是建议别为了追新随意升级课件里教的版本往往最稳妥。前端目录大致是这样disease-frontend ├── public/ ├── src/ │ ├── api/ │ │ ├── auth.js │ │ ├── case.js │ │ └── stats.js │ ├── assets/ │ ├── components/ │ │ ├── CaseDetailDialog.vue │ │ └── StatusTag.vue │ ├── layout/ │ │ └── Index.vue │ ├── router/ │ │ └── index.js │ ├── store/ │ │ └── user.js │ ├── utils/ │ │ └── request.js │ └── views/ │ ├── Login.vue │ ├── dashboard/Index.vue │ ├── case/List.vue │ ├── follow/List.vue │ ├── material/List.vue │ └── system/UserList.vue ├── package.json └── vue.config.js组件化的意义在于复用。病例详情、状态标签、审核弹窗这些组件会在多个页面出现抽出来之后页面代码会瘦很多。4.2 axios封装、Token注入和路由守卫Vue前端和SpringBoot后端通信几乎都用axios。我习惯先封装一个request.js统一处理请求头、响应码和错误提示。import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { if (res.code 401) { localStorage.removeItem(token) router.push(/login) } else { Message.error(res.message || 请求失败) } return Promise.reject(new Error(res.message)) } return res }, error { Message.error(网络异常) return Promise.reject(error) } ) export default service写好了请求封装还需要在Vue Router的全局守卫里拦截未登录用户router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path ! /login !token) { next(/login) } else { next() } })这套组合拳做完登录状态管理就串起来了页面刷新时不会丢登录态Token过期时自动跳回登录页。动态路由方面如果你的菜单表里存了路由信息可以在登录后根据角色返回的菜单数组动态添加路由如果觉得麻烦也可以在前端写死路由再用v-if控制菜单显示。两种方式都能通过答辩动态路由加分更多但工作量也更大。4.3 核心页面怎么实现从上报到审核的交互逻辑登录页做完后最重要的就是病例管理相关页面。列表页的套路基本一致顶部放搜索条件疾病类型、状态、上报时间段中间放操作按钮新增、导出、审核、详情主体是el-table列表状态列用el-tag显示不同颜色底部放分页器新增病例的上报表单要特别注意疾病类型、病例编号、上报人、上报时间这些字段。病例编号可以交给后端生成上报人从当前登录用户的Token信息里解析前端不用让用户填。审核按钮只有在当前用户有权限且病例状态为“待审核”时才显示。如果页面比较多建议把“病例详情”抽成公共组件点击详情时弹出一个抽屉展示病例基本信息、密接列表、随访记录三个Tab页。这块做出来论文里的“系统实现”部分能配好几张图。统计大屏页面建议用ECharts。后端提供按时间分组统计接口前端拿到[{date: 2025-05-01, count: 12}, ...]这种格式后可以画折线图或柱状图。再加一个按疾病类型分组的饼图页面的视觉完整度就上来了。4.4 前后端联调最容易踩的四个坑第一跨域问题。前端开发服务器默认跑在localhost:8081后端跑在8080直接请求会跨域。最简单的办法是在vue.config.js里配代理module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样前端请求/api/xxx时开发服务器会转发到后端浏览器看起来就是同源请求。后端也要配一下CORS防止其他场景下跨域。第二Long类型精度丢失。后端主键是Long类型前端JavaScript的Number类型无法精确表示超过2^53的大整数所以接口返回的id到了前端会变成123456789012345670这种近似值。解决方法是让后端把Long类型的ID序列化成字符串比如在字段上加JsonSerialize(using ToStringSerializer.class)或者在全局配置里统一处理。第三路由模式导致的刷新404。Vue Router用history模式时刷新非首页路径后端服务没有对应的GET接口会返回404。部署到Nginx可以用try_files兜底或者干脆用hash模式。开发阶段用hash模式更省事就是地址栏会有个#。第四请求封装里忘记带Token。很多同学发现登录后调接口还是401大概率就是axios拦截器没生效或者Token存的key名不一致。排查时打开浏览器开发者工具看请求头里有没有Authorization字段一目了然。5. 从源码到可演示成品环境配置、SQL执行与两种部署方式跑通本地环境只是第一步你最后要交付的是一个能给别人演示的项目。这一章我会把部署和演示过程中最常翻车的细节都拎出来说清楚。5.1 本地运行前的一次环境核对我遇到过太多次“源码在我这跑得好好的到你这怎么不行”的情况根因基本都是环境不一致。这套SpringBootVue项目建议的环境如下技术推荐版本说明JDK1.8 或 11大多数SpringBoot 2.x项目都能用Maven3.6 以上管理后端依赖MySQL5.7 或 8.0最好是8.0脚本兼容性更稳Node.js14 以上运行前端构建工具npm6 以上安装依赖IDEA2020 以后普通社区版也可以这里特别提醒一点如果源码里的SpringBoot版本太高比如3.x那么很多老教程里的javax包名要改成jakartaMyBatis-Plus也得换适配版本。做毕设不建议用最新版SpringBoot稳定压倒一切。springboot版本太高带来的依赖冲突排查起来往往比写代码还耗时。后端application.yml里的数据源配置是重点检查项。数据库名、用户名、密码只要有一个不对启动就会报错。模板一般是这样的server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/disease?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: root mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0如果IDEA里要临时改端口可以直接在application.yml里改server.port或者在Run/Debug Configurations的环境变量里配置SERVER_PORT不用改代码。这不是什么高深操作但演示前一定要确认端口没被别的程序占用。5.2 SQL脚本导入命令行和Navicat两个入口执行SQL脚本看起来简单但很多人跌倒在小细节上。命令行方式我上面已经写了这里补充几点容易踩的问题。第一如果你的SQL脚本里没有CREATE DATABASE语句导入前要先建库CREATE DATABASE IF NOT EXISTS disease DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;第二导入中文乱码时在命令行连接参数里加上--default-character-setutf8mb4或者用Navicat打开脚本后把脚本文件的编码转成UTF-8再执行。第三如果你用的是MySQL 8.0驱动要用com.mysql.cj.jdbc.Driver而不是老版的com.mysql.jdbc.Driver。这两者在旧项目里一直是个坑看到ClassNotFoundException时可以先检查这里。第四导入完成后顺手验证一下数据条数SELECT COUNT(*) FROM sys_user; SELECT COUNT(*) FROM dz_case;如果sys_user表里没有管理员账号后面登录页面永远登不进去别提多尴尬。脚本没执行完整时后端启动并不会报错只有业务操作时才会暴露问题。5.3 Vue打包放进SpringBoot还是Nginx部署前端部署这个话题热搜里总能看到“vue打包放进springboot中”确实是一条实用路径。一种方法是完全前后端分离用Nginx托管前端打包后的dist目录再把/api开头的请求反向代理到SpringBoot后端。这是生产环境的常规做法。另一种方法是把前端打包后的静态文件复制到SpringBoot的src/main/resources/static目录下然后重新打包后端。这样最后只有后端一个jar包双击就能启动前后端同一个端口非常适合答辩现场演示不用额外启动Nginx。第二种方式的具体操作前端先执行npm run build把生成的dist目录里的index.html和static、js、css等资源复制到后端resources/static下。需要注意打包后的index.html里引用的资源路径如果是/assets/xx.js那么后端SpringBoot的static目录要能匹配到这个路径通常把目录结构放对就行。如果用了Vue Router的history模式放到SpringBoot里刷新子路由会404。最省事的办法是改成hash模式或者在SpringBoot里写一个Controller把非接口请求转发到index.html。毕设演示我建议直接用hash模式稳定、少坑。5.4 演示现场防翻车清单参加过答辩或给老师演示的同学都懂演示环节是最容易紧张的。我整理了一份自己每次演示前都会过一遍的清单MySQL服务启动了吗Navicat能连上吗后端jar包或IDEA里的服务还在运行吗端口有没有被占数据库连接配置是不是演示机器的密码前端页面打开时浏览器地址是开发服务器还是已经放进了后端staticToken过期没有如果过期了重新登录一次再开始。演示数据够不够列表页和统计图表不能是空的。你可以提前准备一个“演示脚本”按顺序列出登录、新增病例、审核、添加随访、查看统计、物资出库这六步操作每一步用哪个账号、点哪个按钮、预期看到什么结果都写好。真正演示时照着走不仅不慌还会给老师一种“这项目很扎实”的感觉。6. 论文与答辩把源码讲成自己的项目代码能跑只是结果论文和答辩才是把你这份工作“讲出来”的过程。很多同学代码写得还行一写论文就开始从网上复制结果内容和自己的项目完全对不上。下面这些思路可以帮你把源码和论文统一起来。6.1 论文大纲怎么搭一篇标准的Java Web毕设论文结构通常是这样摘要写清楚用了SpringBoot、Vue、MySQL这些技术实现了一个疾病防控综合系统平台包含哪些模块达到了什么效果。绪论项目背景、研究意义、国内外现状。这个部分不需要长篇大论重点是引出你做这个系统的必要性。相关技术介绍SpringBoot框架、Vue框架、MyBatis-Plus、JWT、MySQL。写的时候强调你项目里用了哪些特性不要写一堆用不到的。系统分析需求分析、角色分析、功能需求、非功能需求。系统设计总体架构、功能模块设计、数据库设计、接口设计。系统实现每个核心模块怎么做的配页面截图和核心代码。系统测试功能测试用例、测试结果、性能测试说明。总结与展望。写论文时要画图。用例图、ER图、系统架构图、功能结构图最好自己画别直接截网图。ER图里的表名和字段一定要和SQL脚本里一致这是老师最容易发现“论文和项目脱节”的地方。6.2 高频答辩问题与回答思路下面是这套系统答辩时最常被问到的几个问题你可以提前准备问题1为什么选用SpringBootVue答SpringBoot简化了Spring配置内嵌Tomcat适合快速构建后端服务Vue作为前端框架采用组件化和双向数据绑定适合前后端分离开发。两者结合能提高开发效率也方便后期维护。问题2JWT相比Session有什么优缺点答JWT服务端不保存会话状态天然支持分布式扩展Token里可以携带用户基本信息减少数据库查询。缺点是Token过期前无法主动吊销所以需要设置合理的过期时间并在前端做好401拦截。问题3数据库为什么用逻辑外键不用物理外键答物理外键在批量导入、删除时容易产生约束冲突影响性能逻辑外键由应用层保证关联关系更灵活适合当前系统的数据特点和开发节奏。问题4怎么防止SQL注入答项目里使用MyBatisSQL语句统一采用#{}预编译参数不使用${}直接拼接。预编译时参数不会和SQL语句混在一起解析从机制上规避了SQL注入。问题5项目中遇到的最大难点是什么答比较典型的是Long类型主键传到前端后精度丢失、前后端跨域、多表操作的事务一致性问题。然后结合自己的排查过程说明怎么解决的。这个回答要真实不要编一个太宏大的难题。问题6如果并发量变大怎么办答现阶段数据量还不大通过分页查询、索引优化已经能满足性能要求。后续可以引入Redis缓存热点数据用消息队列削峰或者做读写分离。这个回答的姿态要客观毕设阶段不需要吹得太大。6.3 值得自己动手加的加分功能源码能跑是及格能加一两个自己写的功能才算加分。我建议你在这套系统上做几个小而实的扩展第一用ECharts做一个数据可视化大屏。疾控类项目很适合用地图、折线图、饼图展示病例趋势视觉效果强论文里也能多两张截图。第二增加Excel导入导出。病例列表、随访记录、物资台账都可以通过EasyExcel导出成Excel老师会觉得功能考虑得很全面。第三增加定时统计任务。用Spring Task每天凌晨自动统计前一天的上报数和随访数生成汇总数据体现自动化意识。第四给随访记录加文件上传。随访时可以上传图片附件后端用本地磁盘或OSS保存。这个功能涉及文件上传下载也是答辩时比较好讲的点。有一点必须提醒如果这套源码本来就是网上买的你千万不要直接原封不动交上去。花时间把几个页面的样式改一改把数据库表名前缀换成自己的把某个模块的业务逻辑调一调至少让代码里有自己写的东西。否则老师一问细节连自己都解释不清楚。说实话毕设源码我一向不建议直接交上去你能把这份源码真正“用”起来才有意义。我个人整理这套项目时体会最深的一环是把SQL脚本里的十几张表连起来画业务流程图画通之后后端接口怎么设计、前端页面该放哪些按钮就全顺了。你拿到源码后第一件事也别想着换肤改样式先把“上报—审核—随访—统计”这条链路走通再往上面加自己的东西。照着这个思路答辩时随便问到你哪个类、哪张表、哪个接口你都接得住。