Springboot结合疫情情况的婚恋系统：从需求分析到完整部署的毕设全攻略

每年到了毕业季，总有一批人被毕设选题折磨到头秃。如果你正盯着“Springboot结合疫情情况的婚恋系统d3x17”这个标题发愁，不知道怎么拆解需求、怎么设计数据库、怎么把自己从“只会写CRUD”的焦虑里捞出来，那这篇内容就是给你准备的。我当初做类似项目时，从选题到答辩整整踩了小半个月的坑，今天把这些经验一次性倒出来，你照着走，至少能少走80%的弯路。

这个系统说白了就是一个带疫情健康信息登记的婚恋交友平台：用户注册登录、完善个人资料、浏览推荐对象、申请解锁联系方式，管理员在后台维护用户审核、会员管理、数据统计。放在Spring Boot框架下做，前后端分离也好、服务端渲染也罢，核心业务都是同一套。整个项目适合用来做毕业设计、课程设计，也可以作为Spring Boot入门到进阶的练手项目，一个项目里能用到Web开发、ORM框架、数据库设计、接口调试、部署上线的全套技能。

1. 为什么是Spring Boot，为什么是婚恋系统

1.1 技术选型背后的逻辑

很多同学拿到题目第一反应是：为什么要用Spring Boot？用SSH（Struts2+Spring+Hibernate）不行吗？用Servlet+JSP不更简单？

有这个疑问很正常，但你换个角度想：毕设是要拿给评委老师看的，老师看的不仅仅是功能跑不跑得通，更是你选型是否合理、是否跟得上行业主流。SSH那一套在真实企业项目里已经很难看到新项目在用了，Servlet+JSP更是停留在教学层面。Spring Boot作为当前Java后端开发的事实标准，自动装配、起步依赖、内嵌容器这些特性极大降低了配置成本，而且招聘市场上大量岗位要求的都是Spring Boot经验，无论从项目的实用性、简历的加分项还是答辩的说服力来看，Spring Boot都是最优解。

再说婚恋系统本身，它不像电商系统那样要求高并发、分布式，也不像物联网平台那样要处理复杂的协议对接，它更适合作为一个完整的业务闭环来练手：用户端有注册登录、资料填写、搜索筛选、互动申请，管理端有用户审核、分类管理、统计报表。麻雀虽小五脏俱全，拿来检验Spring Boot后端开发能力正合适。

1.2 结合疫情背景的需求设计

题目里提到了“结合疫情情况”，这部分是区别于普通婚恋交友网站的差异化亮点。当时我做类似设计的时候，把疫情信息做了一个独立模块，而不是生硬地挂在用户资料旁边。

具体来说，我设计了“健康状态登记”功能：用户可以在个人中心填写当前健康状态——绿码/黄码/红码状态的模拟标识（项目里用字符串字段存储）、体温记录、是否接种疫苗、近期是否去过中高风险区域（模拟数据，不需要接真实接口）。在配对推荐时，系统会把“健康状态异常”的用户降低推荐权重，同时在“解锁联系方式”之前，强制要求对方完成当天健康打卡，否则按钮不可用。这样一来，疫情模块就不是摆设，而是真正嵌入了业务流程，答辩时老师问“你为什么要这么做”，你可以有理有据地讲出这个设计逻辑。

提示：一定不要直接去调真实健康平台的接口，既没有权限也没有必要。用模拟状态字段+校验逻辑的方式，就足以体现你对业务场景的理解，答辩重点在于“业务结合点”而不是数据来源。

1.3 功能模块全景拆解

这个系统按照角色来分，核心是三个端：普通用户端、管理员端、系统底层公共模块。

普通用户端包括：注册登录、个人资料管理（基础信息、照片资料页、择偶偏好）、健康状态登记打卡、用户搜索与筛选、推荐列表（按匹配度排序）、查看他人主页、申请解锁联系方式、消息通知（可简单实现站内信或留言）。

管理员端包括：用户审核（新注册用户需要管理员审核通过才能展示）、用户禁用/启用、健康异常用户追踪列表、会员统计（性别比例、年龄分布、活跃度）、系统公告管理。

公共模块包括：统一异常处理、JWT或Session登录拦截、文件上传下载（头像和照片）、AOP操作日志（可选）、定时任务（比如每天0点重置健康打卡状态）。

功能列表整理出来后，你再去数据库建表，会发现之前模糊的地方全都清晰了。

2. 数据库设计与核心表结构

2.1 表结构设计思路

数据库设计是整个项目的根基，根基没打好，后面写代码会越写越难受。我见过太多同学一上来就用Navicat随手建几张表，写着写着发现缺字段，又改表，改完表Mapper又要改，Mapper改完前端传参又对不上，整个项目陷入“改改改”的泥潭。所以建议先用纸笔把表关系画出来，再动手建库。

这个项目的核心表我建议这样设计（MySQL为例）：

这张表里的user和user_profile我故意拆成两张，而不是合并成一张大表。理由很简单：登录认证只需要username和password，如果把身高、收入、自我介绍全部塞在同一张表里，每次登录查询都要多查一堆无关字段，而且用户资料修改频率低、登录频率高，拆开之后互不影响。这个设计在答辩里可以重点讲，体现你对表设计的思考。

2.2 推荐匹配的SQL实现

婚恋系统的核心吸引力在于“推荐”。如果只是把所有用户列出来让用户自己翻，那这个系统就没有灵魂。我的做法是做一个简单的匹配度计算：年龄相仿加30分，城市相同加25分，学历匹配加20分，性别相反加15分，兴趣标签有重叠每一个加5分，上限100分。

推荐列表接口就是一个多表关联查询，核心SQL长这样：

sql复制SELECT u.id, p.nickname, p.age, p.city, p.education,
       (30 - ABS(p.age - #{myAge})) * 0.3 +
       IF(p.city = #{myCity}, 25, 0) +
       IF(p.education = #{myEducation}, 20, 0) + 15
       AS match_score
FROM user u
JOIN user_profile p ON u.id = p.user_id
JOIN health_info h ON u.id = h.user_id AND h.record_date = CURDATE()
WHERE u.status = 'normal'
  AND p.gender != #{myGender}
ORDER BY match_score DESC
LIMIT 20

这个SQL看起来很复杂，但其实拆开就三件事：算分、过滤（只显示当天完成健康打卡的用户）、排序。用ABS函数算年龄差，用IF函数做条件加分，这些都是MySQL内置函数，不需要额外引入复杂计算引擎。答辩的时候可以顺势提出一个优化点：当用户量达到百万级别，SQL实时算匹配分会很慢，可以引入定时任务把匹配结果预计算存储到redis缓存里。这一句话就能让老师对你的系统设计能力刮目相看。

2.3 疫情模块的状态变更设计

健康状态不是固定的，用户今天打卡是绿码，明天可能就变成了黄码，所以健康登记表必须要存“状态变化轨迹”，这也是我单独设计一张health_info表而不是在user_profile里加两个字段的原因。

每个用户每天可以有一条健康记录，用record_date字段来区分。登录之后系统先查当天有没有记录，有则显示“今日已打卡”，没有则提示去登记。管理员后台可以按日期筛选、按状态筛选，做到“追溯”。这里要特别处理一个细节：用户当天重复提交怎么办？我的方案是加唯一索引（user_id, record_date），数据库层面防重，比在代码里各种判断要可靠得多。

注意：数据库字段类型不要全用varchar，体温就不要存成字符串。temperature用DECIMAL(4,1)，health_code用VARCHAR(10)，age用INT，日期统一用DATE，这些细节在你写论文的数椐库设计章节时都会被拿出来检查。

3. 核心功能模块实现：从代码层面拆解关键逻辑

3.1 注册登录与JWT鉴权

这个模块是每个Spring Boot项目的门面，写得干净利落，后面所有功能都顺畅；写得稀烂，后面到处是坑。

我的做法是：集成Spring Security + JWT做无状态认证。用户的密码加密用BCryptPasswordEncoder，不存明文；登录成功后签发一个JWT token，前端每次请求带上Authorization请求头，后端通过OncePerRequestFilter校验token并解析出当前用户。

java复制@PostMapping("/login")
public Result login(@RequestBody LoginRequest request){
    // 1. 校验验证码（可选）
    // 2. 根据username查用户
    User user = userService.getByUsername(request.getUsername());
    if(user == null){
        return Result.error("用户不存在");
    }
    // 3. 校验密码
    if(!passwordEncoder.matches(request.getPassword(), user.getPassword())){
        return Result.error("密码错误");
    }
    // 4. 校验用户状态
    if("banned".equals(user.getStatus())){
        return Result.error("账号已被禁用");
    }
    // 5. 生成token并返回
    String token = JwtUtil.generateToken(user.getId(), user.getRole());
    return Result.success(token);
}

这段逻辑属于“一听就懂、一写就错”的典型。新手最容易踩的坑在第3步：老想用MD5加密，甚至明文存储，这在答辩时是硬伤。另外JWT的secret要放到配置文件中，过期时间也不要设置成永久，正常的做法是设置2小时过期外加refresh token机制（课设做到access token过期即可，不用太复杂）。

3.2 疫情健康打卡模块的完整流程

健康打卡这个功能，看起来就是个INSERT语句的事，实际实现起来要考虑的点不少。我当时做的流程是：

第一步，前端页面展示今日健康状态表单，包含四个字段：健康状态（下拉选择）、体温（数字输入）、是否接种（单选）、近期是否去过高风险区域（单选）。第二步，后端接收请求后先校验参数非空和合法性，体温范围做个简单校验（35.0-42.0之间），超出范围直接拒绝。第三步，检查该用户今天是否已打卡，用(user_id, record_date)查库，存在则提示“今日已打卡，请勿重复提交”。第四步，插入健康记录，并在user表上更新一个last_health_date字段，方便列表页快速判断用户是否完成每日健康打卡。

这里有一个业务细节值得讲给老师听：为什么要更新last_health_date字段？因为首页推荐列表在查询时，如果每次都去health_info表里“连表+按日期过滤”，在数据量大时效率很低。保留一个冗余字段在user表里，查询时直接判断last_health_date是否等于当天，可以省掉一次多表联查。这个就是典型的“用空间换时间”思想，答辩加分点。

3.3 用户资料解锁的关键逻辑

婚恋网站为什么不是把所有用户联系方式直接公开？因为这样就没有互动价值了。我们做“解锁联系方式”的流程，本质上是把平台的社交关系做了一层转化：用户A对用户B感兴趣，点击“申请解锁”，填写一段申请留言，系统生成一条unlike_record记录；用户B登录后可以看到申请列表，选择“同意”或者“拒绝”；如果B同意，A才能看到B的手机号或微信号（敏感信息脱敏存储，比如手机号中间四位打码）。

实现这个功能的核心难点在于数据权限控制。一个用户查询另一个用户资料时，后端要根据当前状态判断哪些字段可以返回、哪些字段要打码处理。通常是通过详情接口里面做判断，不通过就直接返回一个脱敏后的字段：

java复制public UserProfileVO getUserProfileDetail(Long currentUserId, Long targetUserId){
    UserProfileVO vo = new UserProfileVO();
    BeanUtils.copyProperties(profileService.getByUserId(targetUserId), vo);
    // 默认联系方式打码
    vo.setPhone(maskPhone(vo.getPhone()));
    // 判断是否已解锁
    boolean unlocked = unlockService.isUnlocked(currentUserId, targetUserId);
    if(unlocked){
        vo.setPhone(profile.getPhone());  // 解锁，展示完整号码
    }
    return vo;
}

这个模块写好后，整个系统的业务闭环就完整了：注册 → 完善资料 → 健康打卡 → 浏览推荐 → 申请解锁 → 互相联系。做项目一定要有“闭环思维”，不要做了一堆功能却连不成一条线，这是区分一个项目完成度和一个“半成品Demo”的关键指标。

3.4 管理员后台的统计与审核

管理员端不需要做得花里胡哨，但要覆盖核心审计需求。用户审核模块里，管理员可以查看未审核用户列表，通过或驳回，被驳回的用户只能重新提交资料；健康异常追踪模块里，管理员可以按日期筛选出所有体温异常或状态非绿码的用户；数据统计模块里，展示总用户数、今日活跃数、男女比例、年龄分布图（可以用ECharts在前端画柱状图和饼图）。

这里尤其要强调ECharts的使用。Spring Boot本身不负责绘图，但配合后端接口返回统计数据，前端用ECharts画图非常方便——而且这是毕设演示时最容易出效果的部分。你不用自己封装图表组件，直接在HTML里引入ECharts的CDN，十分钟就能出一个好看的仪表盘页面。很多同学把这个系统的后台做得平平无奇，但加了一个统计图表页之后，整个项目的“完成度”一下就上去了，这在答辩时的印象分差别是很大的。

4. 开发环境搭建与项目配置详解

4.1 环境版本怎么选不出错

版本问题是Spring Boot新手最容易翻车的环节。网上教程千千万，但很多教程用的版本和你的版本不一致，照着敲就报莫名其妙的错。结合我实操下来的经验，给出一个稳妥的组合：

这里有一个特别无语的坑：Spring Boot 3.x要求JDK最低17，而很多教程还在用javax.开头的包，Spring Boot 3已经切换到了jakarta.。如果你一上来就用最新版Spring Boot 3.x + JDK 21，然后复制了网上Spring Boot 2.x的代码，那javax.servlet下的类全都找不到，光是改这个包名就要改到怀疑人生。这是我踩过的坑，希望你不要再踩一次。

4.2 核心配置文件参考

application.yml是整个项目的枢纽配置，我直接给一份可直接参考的模版：

yaml复制server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/dating_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: Asia/Shanghai

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
    map-underscore-to-camel-case: true
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

jwt:
  secret: your-secret-key-change-me
  expire: 7200000

几个容易踩坑的地方：第一，MySQL 8.0的驱动类名要写com.mysql.cj.jdbc.Driver，MySQL 5.7用com.mysql.jdbc.Driver，两个版本不通用；第二，serverTimezone必须显式指定，否则会报时区错误；第三，map-underscore-to-camel-case建议打开，这样数据库字段user_name能自动映射到Java属性userName，少写大量@TableField注解。

具体在搭建时，我不会强推MyBatis-Plus还是原生MyBatis。从课设角度，MyBatis-Plus明显省事很多，封装了通用Mapper的增删改查，单表操作不需要写SQL，多表查询还是要写XML。带着“不用背SQL也能做CRUD”的心态去开发，效率能提升一大截。

4.3 Maven依赖：哪些必须引入

pom.xml里引入哪些依赖，直接决定了项目后期开发是否顺利。我的建议是最小化原则，不用的不要提前引，引了反而增加版本冲突概率：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.30</version>
</dependency>
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <optional>true</optional>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>0.11.5</version>
</dependency>

这里要特别提醒：Lombok虽然好用，但在新版本IDEA里要确保已经安装了Lombok插件，否则@Data注解完全不起作用，实体类会各种找不到getter/setter。另外一个常见问题是spring-boot-starter-test自带JUnit 5，但你按JUnit 4的方式写@Test导错包，会导致测试跑不起来，注意用org.junit.jupiter.api.Test。

5. 调试部署全流程与踩坑总结

5.1 用Postman把接口全部过一遍

代码写得差不多了，接下来要系统地测试。很多同学习惯直接在浏览器地址栏里敲地址测试，但GET请求还行，POST请求带JSON，浏览器就玩不转了，这时候你最先要用的是Postman或Apifox。

测试时的核心思路是：按业务链路去串流程。注册一个新用户 → 登录拿token → 完善资料 → 健康打卡 → 搜索推荐用户 → 申请解锁 → 管理员登录审核。一条流程走通了，系统就基本没大问题。每测一个接口，都把请求和响应截图保存下来，这点在做论文和答辩PPT时极其有用。

另外强烈建议把所有接口统一返回Result通用返回体，code表示业务状态码、msg表示提示信息、data表示数据，这样前端拿值判断统一，后端的代码也更干净。如果某些接口直接返回了自定义对象，未来加字段或改异常逻辑时就会非常痛苦。

5.2 打包部署：从IDEA直接跑到服务器运行

本地调试时直接在IDEA里运行main方法即可。需要部署到服务器展示时，用Maven打包：

bash复制mvn clean package -DskipTests

打完包后在target/目录下会生成一个xxx.jar文件，放到服务器上执行：

bash复制java -jar dating-system-0.0.1.jar

首次部署时最容易犯的错误是：打包时因为数据库连不上导致启动失败。记得先检查服务器的MySQL是否已经把你本地导出的SQL脚本执行成功，数据库表是否都在。另外默认端口8080容易被占，启动前先确认端口没被占用：

bash复制netstat -ano | findstr 8080    # Windows
lsof -i:8080                    # Linux/Mac

如果还想要进化一点的部署方式，可以写一个Dockerfile，把jar包打成Docker镜像，然后用docker run跑起来。不过这个不是必选项，如果时间不够，放服务器上用nohup java -jar xxx.jar &跑起来效果也一样。

5.3 常见问题排查对照表

把所有我遇到过、以及周围同学踩过的问题汇总成一张排查表，你遇到了可以先对着表自查：

5.4 数据库脚本的导出与交付

毕设最终交付时需要导出数据库脚本。不要在Navicat里右键“转储SQL文件”就不管了，要注意导出文件里要包含INSERT语句，最好是结构+数据一起导出，这样老师导入时才能看到已经有数据的界面效果。

另外要检查导出SQL中是否包含USE语句和DROP TABLE语句。如果没有USE语句，导入时要手动选择数据库；如果有DROP TABLE，导入时会把已有数据清空，要提醒老师这是覆盖导入。这些都是交付细节，但直接影响老师能否顺利跑起来，毕竟老师没有那么多时间去排查环境问题。

6. 论文与文档：从哪里来，怎么写才不慌

6.1 论文结构怎么搭

题目说了带论文文档1万字以上，很多同学一听就头大。其实1万字看起来很吓人，拆解下来也就五个部分：绪论、系统需求分析、系统设计、系统实现、系统测试。你真正写的时候会发现，代码写完之后，论文素材都是现成的，所谓“难写”只是没找到写的角度。

我写论文时是按这个逻辑建的章节：

第一章：绪论，写课题背景、研究意义、国内外研究现状。国内外现状这块别乱抄，可以把“线上婚恋平台从传统PC端到移动端的发展”“疫情期间线下社交受限催生线上婚恋交友需求”这两个点稍微展开，结合一些数据说话，角度自然不空洞。

第二章：需求分析，写用户角色分析、功能需求用例图、非功能需求（性能、安全性、可用性）。用例图不会画没关系，用思维导图软件拉一个框，截图放上去。

第三章：系统设计，写总体架构图、技术选型对比、数据库E-R图、表结构设计、接口设计。这一张是评阅老师最会细看的部分，表和字段设计如果很混乱，老师一眼就看出来没认真做。

第四章：系统实现，分模块截图+核心代码片段+实现思路描述。每个模块配一句“该模块代码在xxx包下，主要作用是xxx”。保证每个核心功能都有一张页面截图，字数自然就上去了。

第五章：系统测试，写测试环境、测试用例表、测试结果分析。不用真的写自动化测试，但至少写清楚功能测试用例：输入什么、预期结果、实际结果、是否通过。

6.2 论文配图的快速生成技巧

写论文最花时间的不是码字，而是画图。E-R图可以用draw.io或ProcessOn在线画，直接拖拽实体和属性框，导出png图片；架构图也可以用同样的工具画，一个三层架构图（表现层、业务层、数据层）加上简单的箭头标注即可。

页面截图就别用微信截图一张张裁了，直接用IDEA的HTTP Client或Postman先把接口测通，再用浏览器登录系统，把用户端页面、管理员端页面、健康打卡弹窗、统计图表页依次截图，统一裁剪宽度，放到对应章节里。记住一个原则：图片不能太多太杂，但每个核心功能至少配一张，这能让论文的观感完全不同。

6.3 答辩高频问题提前准备

答辩时老师一般会围绕“背景理解、设计决策、技术细节、改进方向”四个维度提问。我整理几个高频问题以及参考回答方向：

你的课题为什么选择结合疫情？回答方向：疫情期间人们线下社交受限，线上婚恋平台的活跃度显著提升，但用户对健康信任度也敏感，所以在婚恋系统里增加健康信息登记与配对过滤，是符合用户实际需求的业务创新。

为什么用MyBatis-Plus而不用Spring Data JPA？回答方向：MyBatis-Plus保留了SQL的灵活可控性，复杂查询（多表连接、条件统计）好处理，而JPA在复杂场景调试起来更隐晦。MyBatis-Plus在中国互联网公司应用广泛，文档中文资源多，学习成本相对低。

系统怎么保证用户信息安全？回答方向：密码采用BCrypt加密存储、JWT无状态token认证、联系方式默认脱敏、管理员操作有日志记录。这几句话一说，老师就知道你考虑过安全问题。

系统有哪些可以改进的点？回答方向：推荐算法可以从简单的规则匹配升级至基于协同过滤或用户画像标签的算法；健康打卡数据可以对接智能接口；系统整体可以微服务化拆分等。不要说自己没想过，主动展示思考深度，印象分会高不少。

7. 开发效率提升与代码质量经验

7.1 善用MyBatis-Plus的封装能力

作为课设级别的项目，很多表操作都是单表CRUD。MyBatis-Plus提供了BaseMapper接口和ServiceImpl类，你甚至不用写一行SQL，就能完成大部分增删改查：

java复制// 继承IService和ServiceImpl，开箱即用
public interface UserService extends IService<User> {
}

@Service
public class UserServiceImpl extends ServiceImpl<UserMapper, User> implements UserService {
}

在Controller里直接注入UserService后，使用lambdaQuery()链式查询非常顺手：

java复制User user = userService.lambdaQuery()
        .eq(User::getUsername, "zhangsan")
        .one();

这套API对新手极其友好，类型安全、IDE自动补全，不会拼错字段名。复杂报表SQL再手写到Mapper.xml里，两全其美。

7.2 统一返回体与异常处理

我强烈建议一上来就把统一返回体和全局异常处理写好，否则后面每个Controller都要重复写“code=200, msg=success”的拼装逻辑，代码会越来越臃肿。

java复制@Data
public class Result<T> {
    private Integer code;
    private String msg;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> r = new Result<>();
        r.code = 200;
        r.msg = "操作成功";
        r.data = data;
        return r;
    }

    public static <T> Result<T> error(String msg) {
        Result<T> r = new Result<>();
        r.code = 500;
        r.msg = msg;
        return r;
    }
}

搭配一个@RestControllerAdvice全局异常处理器，统一捕获的业务异常返回Result.error()，即使用户传了一堆非法参数，前端拿到的也是结构化JSON而不是一堆冗长的异常堆栈。这在答辩演示时的体验差异非常明显——老师大概率会故意乱输入一些数据看你的系统抗不抗造，如果你让老师看到了500报错页面，体验分直接掉一大截。

7.3 定时任务与前端小细节

健康打卡有个隐含需求：每天0点要重置打卡状态。不用设置定时器去把昨天的记录删掉，更简单的做法是查询时用动态条件“今天是否已有记录”来判断，而不是物理清表。如果确实需要定时任务，可以用Spring自带的@Scheduled注解，在启动类加一个@EnableScheduling，然后在某个@Service里写一个每天早上执行的任务，比如统计前一天的用户活跃度，存入统计表。这个功能虽然简单，但也可以作为论文里的“系统特色”来写。

前端方面，建议用Thymeleaf做服务端渲染时，保持所有页面的导航栏统一，用fragment复用代码；用前端分离时，注意配置好跨域和代理。无论哪种方式，都要确保登录状态失效后能跳转到登录页，不要让用户看到空白的报错页面。

8. 写在最后：少走弯路的几点心得

做完这个项目再回头看，它的核心价值不在于功能有多复杂，而在于它完整覆盖了一个业务系统从0到1的各个环节：需求分析、技术选型、表设计、权限控制、业务闭环、测试部署、文档撰写。对于想在Java开发这条路上走远的同学，这个项目练到的每一个环节都有实际意义。

最后分享一个实用建议：开发过程中一定多用Git做版本管理，每完成一个功能模块就提交一次。不要等到最后一团乱麻时再“重建帝国”，第一天把.gitignore配好（排除target目录和IDE配置），在Gitee或者GitHub建一个私有仓库，每天结束时提交一次。这样做有三个好处：代码不丢失、出错能回滚、答辩时可以直接展示commit记录证明工作量——连续一个月的提交记录，比任何口头描述都更能说明你的投入程度。

关于环境搭建和代码调试，你可能会遇到很多稀奇古怪的问题。我的经验是：报错了先去搜索引擎复制原始报错信息搜，多看几篇不同角度的文章再动手改，别一上来就乱试。在动手敲代码之前把技术路线确认好，后面就会顺畅很多。祝你的毕设顺利通过，也欢迎回来在评论区聊聊你踩过的坑。