如果你正在为毕业设计发愁或者想把一套能演示、能答辩的 Java 全栈项目跑起来SpringBoot Vue MySQL的中小社区疫情信息管理系统是一个值得认真考虑的方向。这个题目几乎覆盖了企业开发最常用的三板斧SpringBoot 框架负责后端接口Vue 负责前端页面MySQL 负责数据存储再加上一套完整的关系型数据库设计既能展示编码能力又能体现对业务的理解。更关键的是这类系统带有明确的应用场景把源码、数据库、论文、部署文档全部整理好之后无论是期末答辩还是简历上写项目经验都会很从容。下面我会从需求拆解、数据库建模、后端开发、前端实现、部署上线、论文写作到踩坑实录把整个项目完整过一遍。如果你现在对这套系统只有一个标题概念还不知道从哪儿下手这篇笔记能帮你少走很多弯路。我会直接给出可落地的方案和代码片段也会把容易踩的坑提前标出来照着做就行。1. 做这个毕设前先想清楚的三件事1.1 为什么选这个题目从“能用”到“好答辩”毕业设计最忌讳挑一个“看起来简单但没亮点”的题目比如图书管理系统、课程管理系统这类系统只剩增删改查答辩时老师一句话就能问穿。而社区疫情信息管理系统不一样它天然有“角色”“流程”“状态”“统计”这些元素业务复杂度正好卡在“学生能独立完成”和“老师觉得有工作量”之间。具体来说这个系统至少包含三类角色普通居民、社区工作人员、系统管理员。居民端要做健康上报、信息查询工作人员端要做审核、登记来访信息管理员端要做公告管理、用户管理、数据统计。这里不仅有简单的单表 CRUD还涉及多表关联、状态流转、权限控制、事务处理随便挑一块出来都能在论文里写出一章。而且这类题目有非常强的现实场景。你可以直接在需求分析章节里写“以中小社区为单位采集居民健康信息辅助社区进行异常识别和通知”不需要编造一个假大空的业务背景。答辩的时候评委看到你连“上报-审核-统计-公告”这条完整链路都跑通了会觉得这个项目是真实可用的而不是为了毕业临时拼凑的。从我带过的几个学弟的反馈看这个题目最大的好处是“上下限都高”。做简单版可以只做上报和查询做完整版可以加每日异常数量统计、楼栋分布图、来访登记审核流、导出报表。你先把这个生态位想清楚后面写论文和做功能就不会跑偏。1.2 技术栈选择的取舍SpringBoot、Vue、MySQL的底气技术栈看似是固定的三个关键词其实里面有很多细节值得推敲。后端我建议使用SpringBoot 2.7.x不要一上来就选 3.x。很多同学看到 Spring Initializr 默认给 3.2 或者 3.3觉得很新结果往下拉依赖时发现 MyBatis-Plus、Lombok 的兼容性对不上启动直接报错。SpringBoot 版本太高导致的一系列依赖冲突是每年毕设季最常见的开局劝退原因。实际开发中2.7 已经相当成熟而且可以和 JDK 8 完美配合很多企业老项目也还停留在这一代选它最稳。前端选型有两个方案Vue2 Element UI 或者 Vue3 Vite Element Plus。如果你是跟着视频教程走哪个教程多就选哪个如果你有一定的 JavaScript 基础我更推荐 Vue3 Vite。Vite 启动快组合式 API 写起来代码更清晰Element Plus 的弹窗、表单校验也比旧版更顺手。Vue 安装及环境配置并不复杂Node.js 版本尽量选 16 或 18npm 依赖装不动的时候就用国内镜像或者换成 pnpm这些小问题通常在半小时内能解决。MySQL 用 8.0 就行如果你电脑上装的是 5.7 也完全够用。数据库连接串里要加useSSLfalseserverTimezoneAsia/Shanghai否则非常容易出现 SSL 连接错误特别是 Windows 安装 MySQL 之后默认配置踩中这个坑的概率极高。ORM 层直接用 MyBatis-Plus它能省掉大量重复的 XML 和 BaseMapper 方法。至于很多人提到的 SpringBoot 整合 Flink、Hadoop 这些东西看看就好中小社区数据量根本没有到需要流式计算的量级硬塞进来只会让项目变臃肿答辩时还容易暴露短板。1.3 系统边界中小社区到底要管哪些信息“中小社区”四个字决定了系统不需要考虑高并发、分布式、微服务。我见过有人把这个毕设做成 Spring Cloud Alibaba 微服务架构最后部署时连 Nacos 都没跑起来反而把主流程耽误了。这个系统的数据规模就是几千户居民、每天几百条上报记录单机 MySQL 完全能扛住。所以业务边界要控制好。我们要管的不是医院 HIS 系统那套复杂流程而是四件事居民基础信息和住所绑定姓名、手机号、楼栋、单元、门牌号。每日健康上报体温、是否异常、症状描述、接触情况。来访人员登记和审核访客姓名、身份信息、访问对象、进入时间和体温。社区通知公告和统计展示公告发布、每日上报率、异常人数分布。把这些边界写进论文的需求分析老师一眼就能看出你是否动过脑。不要滥用“物联网”“智能硬件”“人脸识别”这些词除非你真的实现了否则只会成为答辩现场的“高危点”。项目再小只要链路完整就是一个合格的毕业设计项目再大只跑通一个登录页面也过不了关。2. 系统功能设计与数据库建模2.1 角色权限与核心业务流程这个系统的核心是流程不是页面。居民注册登录后绑定自己的住户信息然后每天填写一次健康上报社区工作人员登录后看到待审核的上报记录进行“通过”或“标记异常”操作管理员可以维护社区住户数据、发布公告并查看统计图表。角色权限可以通过一个简单的role字段控制不需要引入 Shiro 或 Spring Security除非你想给自己加难度。登录时生成 JWT前端拦截路由后端拦截接口这样就足够应付毕设答辩。业务流程建议按下述链路设计居民端提交健康上报状态初始为“待审核”。工作人员审核通过后状态变为“已通过”发现异常则标记为“异常待处理”。管理员在统计页面按日期、楼栋查看上报人数和异常数量。社区工作人员登记访客信息结束后更新离开时间。管理员发布社区公告居民端在首页滚动显示。这里最值得写进论文的就是“状态流转”。你可以自己定义一个状态枚举在实体类中写清楚每个状态能跳转到哪个状态。这样既方便代码实现又能在设计章节中画状态图一举两得。2.2 数据库表设计与字段规划数据库设计是整个项目的地基。表结构如果设计错了后面写代码就是灾难。我建议核心表控制在六张以内别贪多。下面是我常用的一套表设计可以直接参考。表名说明关键字段sys_user系统用户表id, username, password, role, real_name, phone, statuscommunity_household社区住户表id, user_id, building, unit, room, full_name, id_card, statushealth_report健康上报表id, user_id, household_id, report_date, body_temp, is_abnormal, symptom_desc, status, audit_remarkvisitor_record访客登记表id, visitor_name, phone, id_card, visited_household, reason, body_temp, enter_time, leave_time, statusnotice_info社区公告表id, title, content, publisher_id, publish_time, top_flagaudit_log审核记录表id, business_type, business_id, auditor_id, action, remark, create_time注意sys_user和community_household之间是一对一关系我故意把住户信息单独拆一张表而不是把楼栋房号直接塞进用户表因为“系统用户”和“社区居民”是两个概念。有的居民可能还没实名绑定也有工作人员和管理员并不是本社区居民拆开后更清晰。建表时明确指定ENGINEInnoDB DEFAULT CHARSETutf8mb4。InnoDB 支持事务utf8mb4 支持生僻字和表情符号避免因为用户输入触发“Incorrect string value”错误。每张表都加上create_time和update_time后面写接口、做统计时你会感谢这个习惯。2.3 关键业务逻辑上报、审核、统计业务逻辑集中在三个地方防重复上报、状态流转、统计聚合。先看防重复上报。一个居民一天只能有一条上报记录最简单粗暴的方式是业务层先selectCount再insert但这在并发场景下会有漏洞。更稳的做法是在数据库层面加唯一索引比如对(household_id, report_date)建唯一约束插入时捕捉主键冲突异常。毕设代码里两种方式都可以但如果你在论文里写“采用唯一索引保障数据唯一性”老师会觉得你考虑得很全面。再看审核。审核操作必须在更新 SQL 中带上前置状态条件UPDATE health_report SET status 已通过, audit_remark #{auditRemark}, auditor_id #{auditorId} WHERE id #{reportId} AND status 待审核这样即使两个工作人员同时点审核第二个人的更新影响行数是 0自然就不会重复处理。这就是典型的乐观锁思路代码量不大但能看出你有并发意识。统计模块常用的 SQL 是按楼栋分组统计异常数量SELECT h.building, COUNT(*) AS total, SUM(CASE WHEN r.is_abnormal 1 THEN 1 ELSE 0 END) AS abnormal_count FROM health_report r JOIN community_household h ON r.household_id h.id WHERE r.report_date 2024-05-20 GROUP BY h.building后端返回这个结果给前端 ECharts 画图整个统计链路就通了。如果涉及多条写操作比如审核同时要插入audit_log和更新health_report记得在 Service 方法上加Transactional这就是 Mysql 事务处理在项目里最直接的应用。3. SpringBoot后端开发实录3.1 项目初始化与目录结构创建项目时打开 IDEA 的 Spring InitializrGroup 可以写com.exampleArtifact 写community-health。依赖只需要勾选 Spring Web、MySQL Driver、LombokMyBatis-Plus 和 Validation 手动加到pom.xml里就行。如果你不清楚版本对应关系直接参考下面的依赖清单。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency /dependencies目录结构按职责分包清清楚楚com.example.community ├── CommunityApplication.java ├── config // WebConfig、MybatisPlusConfig ├── controller // AuthController、ReportController、AdminController ├── entity // User、Household、HealthReport... ├── mapper // 各实体对应的 Mapper 接口 ├── service // 接口和实现类 ├── common // Result、ResultCode、JwtUtil、GlobalExceptionHandler └── interceptor // JwtInterceptorapplication.yml配置好端口、数据库连接和 MyBatis-Plus 日志。IDEA 配置 SpringBoot 服务启动端口有两种方式一种是在application.yml里写server.port: 8080另一种是在 Run Configuration 的 Program arguments 里加--server.port8081后者适合临时切换端口调试。我建议默认 8080前端代理也直接指向 8080减少一个变量。3.2 核心接口设计与参数校验接口设计直接决定前端好不好写。按照资源命名我整理了下面这套接口方法路径说明POST/api/auth/login登录POST/api/auth/register注册POST/api/report/submit提交健康上报GET/api/report/my查询我的上报记录GET/api/report/page分页查询上报记录工作人员POST/api/report/audit审核上报POST/api/visitor/register来访登记GET/api/statistics/daily按日统计异常数量GET/api/notice/list公告列表POST/api/notice/save发布公告管理员Controller 层不要堆业务逻辑也不要直接从 entity 接收不可控的参数。写一个统一的ResultT返回对象包含 code、message、data 三个字段。身体温度校验可以用 Validation 的注解比如体温不能超过 42 度、不能低于 35 度。Data public class ReportSubmitDTO { NotNull(message 体温不能为空) DecimalMin(value 35.0, message 体温不能低于35度) DecimalMax(value 42.0, message 体温不能高于42度) private BigDecimal bodyTemp; private Integer isAbnormal; private String symptomDesc; private String contactHistory; }再用一个全局异常处理器把校验异常转成统一报文前端拿到非 200 的 code 就能弹出提示。这样整个项目的接口风格一致前端 axios 封装也简单。3.3 JWT登录鉴权与拦截器为什么用 JWT 而不是 Session因为前后端分离之后后端不关心请求来自浏览器还是手机JWT 把用户身份编码进一段 token 里每次请求带在 Header 上后端只要验签就能知道你是谁。这在答辩时是一个可以展开讲半分钟的亮点。实现的步骤很简单登录成功后用 JwtUtil 生成 token把用户 id 和角色放进去。前端把 token 存到 localStorage。后端写一个 JwtInterceptor拦截所有/api/**请求只放行/api/auth/login、/api/auth/register。校验失败直接返回 401不进入 Controller。核心拦截器代码大致长这样Component public class JwtInterceptor implements HandlerInterceptor { Autowired private JwtUtil jwtUtil; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer ) jwtUtil.validate(token)) { Integer userId jwtUtil.getUserId(token); request.setAttribute(userId, userId); return true; } response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\message\:\未登录或token已过期\}); return false; } }千万记得把OPTIONS请求放行不然前端跨域调试时预检请求一旦被拦截真正的请求根本发不出去。这是一个非常常见的坑我见过好几个人在这个问题上卡了一下午。3.4 MyBatis-Plus使用与事务优化MyBatis-Plus 最舒服的地方是单表 CRUD 不用写 SQL。你的 Mapper 接口继承BaseMapperTService 继承IServiceT基础方法就全有了。查询时用LambdaQueryWrapper既不拼字符串也不会因为字段改名而报错。LocalDate today LocalDate.now(); LambdaQueryWrapperHealthReport wrapper new LambdaQueryWrapper(); wrapper.eq(HealthReport::getHouseholdId, householdId) .eq(HealthReport::getReportDate, today); HealthReport exist reportMapper.selectOne(wrapper);分页功能需要单独配置 MybatisPlusInterceptor 分页插件否则Page对象翻页不生效。这是一个老坑检查顺序通常是依赖有没有、插件有没有、前端 pageNum 是不是从 1 开始。事务处理上在审核或登记这样的多写操作上直接加Transactional(rollbackFor Exception.class)。rollbackFor 必须显式指定否则默认只回滚 RuntimeException。这个细节写进论文测试章节可以说“对审核接口进行并发测试验证数据一致性”会非常加分。4. Vue前端页面与交互实现4.1 环境搭建与项目初始化前端开发第一件事是安装 Node.js建议 16 到 18 的 LTS 版本。打开命令行执行下面命令创建一个 Vue3 项目npm create vitelatest community-web -- --template vue cd community-web npm install如果你在执行 npm install 时速度很慢或者直接报错大概率是网络问题可以把镜像源切换成淘宝源再用 pnpm 装依赖。Vue 安装依赖这个环节本身不复杂但环境版本混乱造成的玄学报错特别多所以不要在这上面死磕换源、升级 Node、删掉 node_modules 重新安装三步就能解决大部分问题。安装完基础框架后再装几个依赖npm install element-plus axios vue-router4 pinia echartsVite 开发服务器默认跑在 5173后端在 8080前后端端口不一样所以要在vite.config.js里配置代理把/api转发到后端。这样前端代码里的请求地址可以写简单一点。4.2 动态路由与菜单权限这个系统的前端路由不能一次性把所有页面都注册进去因为居民登录后不应该看到工作人员审核页面。做法是在登录成功后根据后端返回的角色字段动态生成菜单和路由。先定义基础路由包括/login、/home、/403。然后在路由守卫里判断用户身份匹配对应权限的路由表用router.addRoute动态挂载。Vue Router 的beforeEach守卫可以写router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (!token to.path ! /login) { next(/login); } else if (token to.path /login) { next(/home); } else { next(); } });提到 Vue 路由参数这里有params和query两种传参方式。比如从上报列表跳到详情页可以用router.push({ name: reportDetail, params: { id: row.id } })如果只是带个筛选条件用query更简单。动态路由是你论文里可以专门画图讲解的点面试官也很爱问。4.3 页面组件与数据展示页面按功能分成三大块不太多但每一块都要做得完整登录和注册页面表单校验、角色选择。居民端页面首页公告、每日上报、历史记录。管理端页面用户管理、上报审核、来访登记、统计分析。健康上报页面是核心表单里有一个体温输入框。前端要加校验规则体温超过 42 度直接拦截不给后端增加无意义请求。上报表单提交成功后刷新历史记录表格表格用 Element Plus 的el-table展示日期、体温、状态、备注状态用el-tag变色区分。统计页面用 ECharts 画折线图和柱状图从后端拿统计数据代码不复杂但视觉效果会让整个系统显得饱满很多。4.4 前后端联调注意点最常见的问题就是“前端调不通后端”。先检查浏览器 Network 面板看请求有没有发出去、返回状态码是多少。如果是 404大概率是路径写错如果是 401大概率是 token 没带如果是跨域报错先确认 Vite 代理有没有生效再看后端有没有配置 CORS。axios 封装成统一实例是必须的const request axios.create({ baseURL: /api, timeout: 10000, }); request.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; }); request.interceptors.response.use( response response.data, error { ElMessage.error(error.response?.data?.message || 服务器异常); return Promise.reject(error); } );国内外很多人喜欢在这里加各种酷炫功能比如 vue 播放 m3u8 免安装、富文本编辑器、地图组件这些和本项目主流程无关不建议在毕设阶段引入。先把主流程调通再考虑锦上添花。5. 数据库部署与系统部署5.1 MySQL安装与建库数据库是整套系统的底座部署环节最容易出问题。Windows 安装 MySQL 8 的教程到处都是核心注意点有两个一是安装时选择 Server only不要装一堆无关组件二是记住 root 密码密码忘了后面很麻烦。如果你是在云服务器上部署也可以选择 rpm 安装 MySQL这里不展开安装完成后用 Navicat for MySQL 连接测试连接成功后再导入 SQL 脚本。新装 MySQL 8 后很多旧版 Navicat 会报错比如Authentication plugin caching_sha2_password cannot be loaded或者 SSL 连接错误。这是因为 MySQL 8 默认的密码加密方式和旧版本不兼容。解决办法是改一下 root 用户的认证插件ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码; FLUSH PRIVILEGES;如果项目要部署到云服务器还要把localhost改成%或者创建一个专门的应用账号避免 root 被远程连接风险太大。数据库导入时先创建库CREATE DATABASE community_health DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE community_health; SOURCE /path/to/community_health.sql;5.2 SpringBoot项目打包与配置后端打包很简单在项目根目录执行mvn clean package -DskipTests打包产物是target/community-health.jar。部署时一般会区分开发环境和生产环境可以在application.yml旁边放一个application-prod.yml生产环境里指定正式数据库地址、数据库账号密码和端口号。启动命令建议写成java -jar community-health.jar --spring.profiles.activeprod --server.port8080如果想让日志不滚屏可以用nohup放到后台nohup java -jar community-health.jar --spring.profiles.activeprod app.log 21 看到日志里出现Started CommunityApplication就说明启动成功。这时先在浏览器里访问一下后端接口比如http://ip:8080/api/notice/list能返回 JSON 再继续部署前端。5.3 Vue打包并整合进SpringBoot前端打包有两种思路。第一种是用 Nginx 托管dist目录这也是前端项目最标准的方式。执行npm run build后把dist目录上传到服务器在 Nginx 配置里做反向代理。server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/community-web/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/api/; } location / { try_files $uri $uri/ /index.html; } }第二种方式更省事直接把dist目录里的静态文件复制到 SpringBoot 的src/main/resources/static目录下然后重新打包后端 jar。这样启动一个 8080 端口就能同时访问前端页面和后端接口完全同源没有跨域问题。Vue 打包放进 SpringBoot 中的思路很适合毕设答辩场景方便演示不用额外装 Nginx。但要注意如果你的前端路由是 history 模式直接刷新http://ip:8080/report会出现 404。解决办法是加一个资源兜底配置把未匹配的路径转发到index.html或者在 tomcat 层面做 rewrite。如果是 hash 模式就不会有这个问题但 URL 上会多个#看起来不专业。5.4 部署文档编写要点“部署文档”属于整个交付物里最能体现工程素养的部分。一份合格的部署文档不需要长篇大论但必须能让一个从没接触过你项目的人按步骤把系统跑起来。我建议按以下目录写环境要求JDK 1.8、MySQL 8、Node 16、Maven 3.6。文件说明后端 jar、前端 dist、数据库脚本、附件目录。数据库初始化连接 MySQL、执行脚本、验证表数量。后端部署修改数据库配置、启动 jar、查看日志。前端部署Nginx 安装、配置文件、重启服务。验证流程访问登录页、使用普通用户和管理员账号分别登录。常见问题端口被占用、数据库连接失败、前端白屏等。部署文档写得好答辩老师可能会现场按照文档自己跑一遍这个体验比你讲十页 PPT 都有效。如果你是部署到云服务器记得在安全组里打开 80 和 8080 端口否则浏览器永远访问不到。6. 论文写作与答辩准备6.1 论文结构框架毕业论文和项目代码同等重要甚至可以说论文决定你最终能不能拿到优秀。这套系统对应的论文结构可以这样组织摘要和 Abstract中文摘要控制在 300 字写清楚背景、技术、功能和成果。第一章 绪论课题背景、研究意义、国内外现状。第二章 相关技术介绍SpringBoot、Vue、MySQL、MyBatis-Plus。第三章 需求分析可行性分析、角色分析、功能需求、非功能需求。第四章 系统设计总体架构设计、功能模块设计、数据库设计。第五章 系统实现核心代码逻辑、界面展示、重点模块说明。第六章 系统测试测试环境、测试用例、功能测试结果、性能分析。总结与展望、参考文献、致谢。这套结构是标准的“毕设八股”不新颖但绝对稳妥。相关技术栈那章可以参照类似的基于 SpringBoot 的校园教职员工考勤管理系统设计与实现论文写法把核心框架讲明白就行不要大段抄官方文档。6.2 核心章节怎么写需求分析章节不要只写“系统需要实现用户管理”而要画出角色用例图分角色列出功能列表。系统设计章节要放总体架构图前端是 Vue Axios ECharts后端是 Controller-Service-Mapper 三层数据库单独画一张 ER 图。系统实现章节要配合页面截图每个功能模块截一张页面图再贴上关键代码代码不要超过 20 行否则排版很难看。系统测试章节最容易被学生忽略但其实写起来最容易出彩。至少写十个测试用例包括正常登录、错误密码、体温越界、重复上报、未登录访问接口、管理员审核、公告发布等。每个用例都写清楚前置条件、输入、预期结果和实际结果最后写一句“测试结果与预期一致系统满足需求分析的要求”。这样测试章节就有理有据了。6.3 答辩演示的关键路径答辩时间通常只有十到十五分钟所以演示流程必须提前设计。我建议按这个顺序走登录页面演示说明三种角色账号可以切换。居民端提交健康上报、查看历史记录。工作人员端审核上报、标记异常、来访登记。管理员端发布公告、查看统计图表。收尾时强调项目亮点JWT 鉴权、唯一索引防重复、事务处理、动态路由。提前准备好老师可能问的问题例如为什么不用 SessionMyBatis-Plus 分页插件怎么工作重复上报是怎么防住的有没有考虑并发情况每一个你都要能顺手答出来。最后老师如果问系统的不足不要直接说“没有”可以提一句“目前缺少消息主动推送后续可以接入微信通知或 WebSocket”这会显得你有扩展意识。7. 踩坑实录与经验总结7.1 常见问题速查表我把实际操作中遇到最频繁的问题整理成一张表方便你排查。问题现象可能原因解决思路后端启动报 DataSource 错误数据库没连上、密码错误检查数据库服务和 application.yml 配置MySQL 报 SSL 连接错误连接串缺少 SSL 参数URL 加useSSLfalseserverTimezoneAsia/ShanghaiSpringBoot 版本太高导致依赖冲突使用 3.x 且 MyBatis-Plus 版本不兼容降级为 SpringBoot 2.7.xLombok 注解不生效IDEA 未开启 Annotation Processing打开设置勾选 Enable annotation processingMyBatis-Plus 分页不生效缺少分页插件注入 MybatisPlusInterceptor前端 npm install 失败网络、Node 版本不兼容换镜像源、升级 Node前端请求跨域Vite 代理没配或后端没配 CORS检查 vite.config.js 和 CorsConfig登录接口返回 401token 没放行或过期检查拦截器放行路径和 JWT 过期时间上传文件报太大Spring 上传限制调大 multipart 配置刷新页面 404前端 history 路由未兜底Nginx 配 try_files或改 hash 路由日期数据显示“一串数字”前后端日期格式不一致后端配置 Jacksondate-format和 timezone审核操作重复处理缺少状态条件使用UPDATE WHERE status待审核上面这些坑几乎每一个都能在某篇博客里找到完整案例。你遇到问题时先把现象输入搜索框再对照这个表确认方向通常五分钟内能定位。7.2 我的个人经验与建议代码写完只是第一步真正让项目立得住的是“文档闭环”。我建议你拿到这个毕设题目之后不要急着一上来写代码先花半天时间把数据库表和状态流转梳理清楚。数据库设计定稿后后端写起来会非常顺前端也不会频繁改接口字段。整个项目按“数据库 - 后端接口 - 前端页面 - 部署 - 论文”的顺序推进比一边写一边改要节省三分之一的时间。第二个建议是全程用 Git 做版本管理。不要求掌握多复杂的命令每天提交一次就算合格。答辩前如果功能改崩了git checkout反而比重新改代码靠谱。我见过不少学生平时不提交最后一天代码打不开只能哭着说“我明明写好了”。有 Git 记录至少能证明你项目推进过程中的每一步。最后一个建议是趁早把项目部署到云服务器上或者哪怕部署到本机虚拟机里也行。你想想答辩老师看到你网页能打开、数据能流动、图表能变化和一个只看到 PPT 截图的项目评价是完全不同的。预先准备一个演示账号登录进去了主流程点一遍这个项目的完成度就已经超过一半人。剩下的就是你带着这套完整源码、数据库、论文和部署文档自信地去答辩就好。