尧图网页设计 
1. 相亲网站管理系统这类Java项目到底在做什么1.1 从基本增删改查到业务闭环打开各大毕设选题列表你会发现XX管理系统占了半壁江山图书馆管理、宿舍管理、停车场管理……而基于SpringBootVue的相亲网站管理系统属于这里面比较特殊的一个。它表面上依然是标准的JavaWeb三层架构SpringBoot管后端、Vue管前端、MySQL存数据、MyBatis做ORM但业务上却比普通的单表增删改查多了一层有意思的东西——匹配、喜欢、互选、推荐。这些东西才是项目真正能和人聊出干货的地方。如果你正在准备毕业设计、课程设计或者单纯想用一套完整项目巩固SpringBootVue这套技术栈这个题目很值得做。原因有几个第一它覆盖了当前就业市场上Java后端最主流的框架组合第二它包含用户端和管理员端两套逻辑功能量足够撑起一篇论文的系统设计和系统实现章节第三它天生自带数据关系问题——一个用户喜欢谁、谁又喜欢他、两个人是否配对成功这些关系在数据库里怎么设计、在接口里怎么流转本身就是很好的面试素材。先把这个系统的功能全景摆出来。整个系统按角色分有三类使用者普通用户相亲者、管理员和系统本身。普通用户能做的事情包括注册登录、完善个人资料年龄、身高、学历、职业、收入、城市、兴趣爱好、个人介绍、浏览推荐的人选、对感兴趣的用户表达喜欢、收到喜欢通知、查看互选配对结果以及发私信、给平台留言反馈。管理员端主要是用户管理审核、禁用、删除、资料审核、反馈处理、数据统计。看到没这个功能量已经覆盖了典型管理系统该有的所有模块注册登录、个人信息维护、列表查询、详情查看、状态流转喜欢→互选、站内通信、后台管理。每一块都对应着SpringBoot里的Controller、Service、Mapper以及Vue里的页面组件和API调用。1.2 用户端和管理员端的功能矩阵我习惯在动手写代码之前先把功能矩阵画出来不然写到哪里算哪里最后肯定一堆返工。下面是这个相亲系统的完整功能拆解用户端功能注册/登录用户名密码注册登录后返回token个人资料管理基本信息增删改、头像上传、兴趣爱好标签维护推荐列表根据当前用户的条件展示推荐人选卡片用户详情查看对方完整资料发起喜欢喜欢与匹配你喜欢的列表、喜欢你的列表、配对成功的列表私信聊天配对成功后双方可以发消息个人中心修改密码、查看自己的配对记录、退出登录管理员端功能管理员登录独立账号体系和用户表分开用户管理查看所有注册用户禁用/启用账号资料审核新注册用户的资料需要管理员审核通过后才对外可见反馈管理处理用户投诉和留言数据看板注册人数、配对数量、每日活跃等统计这些功能看着多但每个都不难核心难点只有两个一是用户之间的喜欢-配对关系数据模型怎么设计二是推荐列表的条件过滤怎么实现得既简洁又实用。后面我会重点讲这两块。1.3 技术栈选型SpringBootVue为什么站得住技术选型这块老实说对于毕设和课设项目选别人都在用的主流技术栈比选我觉着很酷的冷门技术栈重要得多。为什么因为你有问题的时候能搜到答案答辩老师看着眼熟不刁难你以后简历上写出来别人也认。SpringBootSpringMVCMyBatisMySQLVueElement UI/Ant Design Vue这套组合属于Java Web领域最经典的组合拳。SpringBoot负责快速搭建项目和自动化配置SpringMVC处理HTTP请求路由MyBatis作为ORM层SQL自己控制灵活且适合讲出性能优化的故事后面我会提到MyBatis的一二级缓存怎么结合实际业务场景打开MySQL存数据Vue做单页应用配合Axios调接口。其中MyBatis是一个值得多说两句的点。它不同于JPA/Hibernate那种全自动的ORMMyBatis是半自动的SQL还是要你自己写。很多人第一次接触会觉得麻烦——明明Hibernate不写SQL挺爽的。但实际到了生产环境尤其是复杂查询、多表关联、需要手动控制SQL性能的时候MyBatis的优势非常明显。在这个相亲系统里推荐列表的查询、喜欢记录的查询都是多表关联加条件拼接用MyBatis的XML写动态SQL比在用Hibernate里拼Criteria要直观得多。而且面试时为什么用MyBatis这个问题也比为什么用JPA好回答得多我能控制SQL能针对慢查询优化能自己处理复杂关联。关于版本选择我给一个稳妥的组合SpringBoot 2.7.x别一上来就上SpringBoot 3JDK版本和部分兼容性问题能让新手折腾三天、JDK 1.8、MySQL 5.7或8.0、MyBatis 3.5.x、Vue 2.x Vue CLI或者Vue 3 Vite看你自己熟悉哪个、Element UIVue2配Element UIVue3配Element Plus。2. 数据库设计相亲业务的核心是找关系2.1 八张核心表的职责划分数据库是整个系统里最不能糊弄的部分。业务可以简单增删改查可以朴素但表结构设计得好不好直接决定你后面的代码能写多轻松。我在设计这个相亲网站的表结构时最终收敛为8张核心表。先把表列出来表名职责关键字段user用户账号表管登录id, username, password, status, created_atuser_profile用户资料表和user一对一user_id, real_name, gender, age, height, education, income, city, avatar, intro, tagsadmin管理员账号id, username, password, rolelike_record喜欢记录表id, user_id, target_id, is_matched, created_atmatch_record配对记录表id, user_one_id, user_two_id, matched_atmessage私信聊天表id, from_user_id, to_user_id, content, is_read, created_atfeedback留言反馈表id, user_id, content, reply, statusaudit_log资料审核记录表id, user_id, admin_id, action, reason, created_at这里面有两个设计上的关键决策我单独说一下。第一用户账号表和用户资料表为什么要拆开。很多新手做这种项目喜欢一张表搞定user表里又放username又放身高体重。我建议拆开原因有三一是账号信息和相亲资料信息的访问频率不一样登录只需要查user资料列表只需要查user_profile拆开能让每个查询更轻二是权限边界清晰user表里不要放手机号、真实姓名这类隐私user_profile里也不要放密码三是后面如果要扩展会员体系、实名认证加表就行不用动老表结构。第二like_record这张表的设计决定了整个匹配逻辑的复杂度。一个用户对另一个用户表达了喜欢就插一条记录user_id是主动喜欢的人target_id是被喜欢的人。当两个人互相喜欢时我们看到有(user_id1, target_id2)和(user_id2, target_id1)两条记录就是配对成功。这是最朴素也最不容易出错的互选模型。2.2 关系型数据如何支撑喜欢与配对来细看这个互选逻辑因为它是整个相亲系统的灵魂。假设用户A对用户B点了喜欢按钮后端做的事是往like_record插入一条(user_idA, target_idB)。然后立刻查一下是否存在反向记录(user_idB, target_idA)。如果不存在返回已喜欢如果存在说明是互相喜欢这时做两件事一是把两条like_record都标记为is_matched1二是在match_record里插入一条配对记录(user_one_idA, user_two_idB)。这个流程里有一个细节需要注意——判断互选时要用组合查询而不是遍历。正确SQL是SELECT id FROM like_record WHERE user_id #{targetUserId} AND target_id #{currentUserId} AND is_matched 0 LIMIT 1;查到就是互选查不到就是单向喜欢。用联合索引(user_id, target_id)覆盖这张表的查询场景速度非常快。match_record为什么单独建一张表而不是只靠like_record里的is_matched字段因为配对是用户业务上的里程碑后面会不断被查询我的配对列表、管理员的数据统计、消息通知里恭喜你们配对成功。单独成表查起来简单字段干净。而且后面要扩展解除配对功能只需要删match_record记录并更新like_record的状态不需要去翻like_record里那两条互相纠缠的记录。一个表管一个业务动作职责单一这是设计水平的一种体现。2.3 字段设计的几个关键决策字段级别有几个点值得单独拿出来说说都是我自己做过之后才意识到重要的。年龄存birthday而不是age。这是数据库设计的经典常识但也是新手最容易踩的坑。如果存age明年系统里所有人年龄都不对你总不能半夜跑个定时任务给所有用户年龄加一。存birthday查询时用TIMESTAMPDIFF(YEAR, birthday, CURDATE())计算年龄上面的问题就不存在了。性别和学历用枚举还是数字字典。用数字加字典表或者注释说明都行但不要直接存中文字符串。原因很实际第一中文占存储空间第二排序过滤不方便第三前后端可以通过字典映射成统一的中文显示。我习惯用tinyint性别1男2女学历1高中2大专3本科4硕士5博士数据库里加注释后端枚举类管理。text字段慎用。个人简介、职业经历这种可能很长的内容用text没问题。但一个典型的误区是把所有varchar都设成255的长度——数据库的varchar虽然灵活但设置过短会导致数据丢不了也存不下设置过长又会影响索引效率。我一般是名称、城市、学历这类字段varchar(50)头像URL、用户名varchar(100)个人简介text。所有表都要有create_time和update_time。这不是废话。管理后台的数据统计、测试阶段的排查问题、面试时谈我从审计日志里发现……的案例都靠这些时间字段。MyBatis里用insert和update时手动NOW()就行别嫌麻烦。avatar不要直接存图片文件存URL路径。图片文件上传到服务器的upload目录数据库里只存访问路径。这个设计好处是数据库体积可控、分布式部署时可以把图片迁移到对象存储。用户状态status要有软删除意识。用户可能被管理员禁用也可能自己要注销。不要在表里直接DELETE用一个status字段控制0禁用 1正常。这样数据可追溯测试和恢复都方便。索引方面除了每张表的主键索引我还会在下面几个位置建立索引like_record(user_id, target_id)组合查询互选时走这个索引。match_record(user_one_id, user_two_id)查个人配对记录走这个索引。user_profile(gender, city)推荐列表按性别城市过滤时走这个索引。还有如果你的MySQL版本是8.0可以考虑在user_profile.city字段上建一个普通索引就行不用建组合索引的必要因为推荐列表通常还需要按年龄排序而年龄是计算出来不是直接存的后面我会说这个查询怎么处理。3. 后端实现登录鉴权、匹配推荐与服务端接口3.1 项目工程结构与统一响应体后端工程结构我按主流方式组织目录清晰答辩时也好讲src/main/java/com.example.dating/ ├── config跨域配置、拦截器配置 ├── controllerREST API层 ├── service业务逻辑层 ├── mapperMyBatis数据访问层 ├── entity数据库实体类 ├── common统一返回体、异常处理、常量 ├── utilJWT工具类、加密工具类 └── DatingApplication.java代码写之前先把统一返回体定义了。为什么要统一前端Axios拦截器需要统一判断返回状态后端每个接口都返回自己的结构会让前端处理起来像噩梦。统一返回体长这样public class ResultT { private Integer code; // 200成功其他失败 private String message; // 提示信息 private T data; // 数据 public static T ResultT success(T data) { ... } public static T ResultT error(String message) { ... } }加上一个全局异常处理器用RestControllerAdvice捕获Service层抛出的业务异常转换成统一返回体。这些是SpringBoot开发的基础素养写进项目里会让整体代码质量看起来高一个档次。3.2 登录鉴权与密码存储的安全底线登录鉴权我用JWT理由很直接无状态、好扩展、社区资料多。用户在登录接口提交username和passwordService层先用userMapper.findByUsername(username)查出账号比对密码成功则生成一个token返回前端前端存到localStorage之后每次请求在Authorization头带上token后端拦截器解析token得到当前用户ID。// 登录逻辑核心代码 public LoginResponse login(String username, String password) { User user userMapper.findByUsername(username); if (user null) { throw new BusinessException(用户名或密码错误); } if (!BCrypt.checkpw(password, user.getPassword())) { throw new BusinessException(用户名或密码错误); } if (user.getStatus() 0) { throw new BusinessException(账号已被禁用请联系管理员); } String token JwtUtil.generateToken(user.getId(), user.getUsername()); return new LoginResponse(token, user.getId()); }这里我特别强调一点密码存储不要用MD5不要用SHA至少用BCrypt加盐加密。我知道很多毕设项目都是老代码模板复制的密码全是MD5。但在2025年这个时间点你简历上写着我对密码做了MD5加密是会直接被面试官扣分的MD5撞库破解已经很容易BCrypt加盐后暴力破解成本极高。Spring Security crypto工具包里直接有BCrypt实现引入一个依赖就行代码就一行BCrypt.hashpw(password, BCrypt.gensalt())。成本几乎为零收益是安全底线的达标。JWT的密钥要放在application.yml里别硬编码在代码里。过期时间我设置7天因为相亲网站用户没事不会天天来太短要频繁登录太长token泄露风险大。3.3 推荐算法不是随机捞几条那么简单推荐列表这个功能表面上是个列表查询但做得好不好直接关系到这个项目答辩时你是有东西讲还是只能背代码。我的实现思路分三档由浅入深第一档是基础条件过滤。查询user_profile时过滤掉性别相同的、过滤掉自己、过滤掉已经喜欢的防止重复推荐、过滤掉资料未审核的。SQL大致是SELECT p.* FROM user_profile p LEFT JOIN like_record l ON l.user_id #{currentUserId} AND l.target_id p.user_id WHERE p.gender ! #{myGender} AND p.status 1 AND l.id IS NULL ORDER BY p.user_id DESC LIMIT #{offset}, #{pageSize}第二档是加排序权重。条件过滤太冰冷了用户看到的结果是没头没尾的。可以按用户自身填写的理想对象要求来打分年龄范围匹配加多少分、城市一致加多少分、学历不低于要求加多少分、兴趣爱好有重叠加多少分。在Java里写一个打分器或者干脆在SQL里用CASE WHEN做分数计算。第三档是加入活跃度和时间衰减。新注册用户优先展示最近登录活跃的用户优先展示。这个在毕设里可以用ORDER BY里加字段实现真正生产上会用Redis的ZSet做但毕设阶段不用那么复杂。我的建议是做到第二档就很好了代码实现不复杂但是能讲清楚为什么不同用户看到的结果是不同的。public ListUserProfileVO recommendList(Integer currentUserId, int page, int pageSize) { // 1. 查当前用户资料用于过滤和打分 UserProfile myProfile userProfileMapper.findByUserId(currentUserId); // 2. 基础过滤性别相反、状态正常、未审核通过、未喜欢过 ListUserProfile candidates userProfileMapper.findCandidates( myProfile.getGender().equals(1) ? 2 : 1, currentUserId, page, pageSize); // 3. 打分排序 return candidates.stream() .map(profile - toVO(profile, computeScore(myProfile, profile))) .sorted((a, b) - b.getScore() - a.getScore()) .collect(Collectors.toList()); }打分器的规则用Map配置好每个条件一个权重城市相同30分年龄在期望范围内25分学历不低于期望20分兴趣爱好交集≥2个15分这样推荐列表排出来就有逻辑了答辩时老师问你的推荐策略是什么你就能从规则打分和排序讲到数据智能延展性很强。3.4 喜欢、互配、私信的接口逻辑喜欢接口是另一个核心。我在前面第2章讲过表设计这里把完整的Service逻辑贴出来Transactional public MatchResult likeUser(Long currentUserId, Long targetUserId) { // 1. 不能喜欢自己 if (currentUserId.equals(targetUserId)) { throw new BusinessException(不能对自己表达喜欢); } // 2. 不能重复喜欢 if (likeRecordMapper.exists(currentUserId, targetUserId)) { throw new BusinessException(你已经喜欢过对方了); } // 3. 插入喜欢记录 likeRecordMapper.insert(new LikeRecord(currentUserId, targetUserId)); // 4. 查对方是否喜欢了自己 LikeRecord reverse likeRecordMapper.findReverse(targetUserId, currentUserId); if (reverse ! null) { // 互选成功更新状态 插配对记录 likeRecordMapper.markMatched(currentUserId, targetUserId); likeRecordMapper.markMatched(targetUserId, currentUserId); matchRecordMapper.insert(new MatchRecord(currentUserId, targetUserId)); return MatchResult.MATCHED; } return MatchResult.LIKED; }这里有个细节要注意用了Transactional。因为插喜欢记录和更新互选状态是对应着同一个业务事件的两个数据库操作要么都成功要么都不成功不能用事务的各管各的。私信模块我做的相对克制——配对成功后才能发消息非配对状态发私信在接口层直接拦截。这样做有几个好处一是业务逻辑上符合相亲场景你都不喜欢人家凭什么骚扰人家二是避免消息表被垃圾数据灌爆。前端聊天界面轮询接口获取新消息实现即时性足够用了如果要做得更好可以在后面扩展WebSocket这个我在第6章会提。4. Vue前端从页面到交互4.1 前端项目结构与路由设计前端我建议直接用Vue CLI或者Vite初始化一个脚手架项目目录结构按views组件化的方式来src/ ├── api/axios封装 各模块接口定义 ├── router/路由配置 ├── store/Vuex或Pinia存登录状态 ├── views/页面组件 │ ├── Login.vue │ ├── Home.vue推荐列表 │ ├── ProfileDetail.vue用户详情 │ ├── MatchList.vue配对列表 │ ├── Message.vue私信聊天 │ ├── Personal.vue个人中心 │ └── admin/管理员相关页面 ├── utils/工具类 └── App.vue路由的精心设计之处在于路由守卫这是Vue前端拦截器中能不能控制访问权限的关键// router/index.js router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { next(/login); } else { next(); } })凡是需要登录才能访问的页面路由meta标记requiresAuth: true未登录状态直接踢到登录页。这个实现五步就能讲完但它是整个前端安全访问控制的核心答辩时属于为什么这样的设计的好问题。4.2 核心页面推荐列表、用户详情、个人中心推荐列表页面是整个用户端的门面。我用的是卡片流布局每个卡片展示头像、昵称、年龄、城市、一句签名右下角一个喜欢按钮。页面加载时调用/api/recommend接口拿到推荐列表数据渲染到卡片网格里。这个页面的两个开发细节需要特意说第一个Axios请求拦截器统一带token。我没在每个请求方法里手动加token而是在request.js里统一拦截service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] Bearer ${token}; } return config; });第二个喜欢按钮的即时反馈。用户点了喜欢按钮立刻变成已喜欢并置灰避免重复点击。这里的接口返回如果包含MATCHED状态那就弹出成功提示恭喜你们匹配成功去发消息吧并更新配对列表数据。用户在这个环节的体验快感是用户留存的关键。用户详情页展示完整资料基本资料、学历职业、兴趣爱好标签、个人简介。资料展示完了页面最显眼的位置还是喜欢TA按钮和推荐卡片的逻辑打通。这里要特别注意详情页里不要展示对方手机号、微信号等联系方式一是隐私保护的需要二是鼓励用户通过平台私信交流这正是相亲平台存在的意义。个人中心页就是我的资料、我的喜欢、喜欢我的、我的配对、修改密码这些入口。其中喜欢我的列表特别能拉用户回来一条条有人对你心动了的通知比任何运营活动都有效。所以我在个人中心设计了一个未读消息数量和喜欢数量的小红点逻辑。4.3 后台管理页面的表格化实现管理员的页面我用Element UI的el-table组件来做这是后台管理系统最典型的形态。用户管理表格展示ID、用户名、姓名、性别、年龄、城市、学历、状态、注册时间、操作。操作列里有禁用/启用和查看详情两个按钮。禁用调用后端接口修改user.status前端表格刷新。这里有个交互上的注意点禁用之后该用户的所有点赞、配对操作后端都要拒绝——不是前端按钮灰不灰的问题是后端接口要做状态校验。我在后端的拦截器里加了校验逻辑token解析出用户ID后先查一下status为0直接返回账号已被禁用。数据看板页面我用el-card加几个大数字展示注册用户总数、配对成功总数、今日新增用户、今日配对数量。这些数据的SQL都是简单的COUNT(*)查询。如果想让这个页面看起来更高级可以用ECharts画一个最近7天注册趋势的折线图半小时能搞定但界面效果提升一个档次。毕设文档里也多一张功能截图可以说。5. 完整启动步骤与踩坑记录5.1 从零到运行数据库初始化、后端启动、前端启动这节写给第一次跑这类项目的同学。很多人项目代码有了本地环境起不来半天时间耗在环境配置上非常耽误事。下面是我实测下来最顺的流程。第一步准备环境。装好JDK 1.8、Maven 3.6、MySQL 5.7或8.0、Node.js 14Vue2或16Vue3。检查mvn -v、node -v、mysql --version都能输出版本号。第二步初始化数据库。在MySQL里创建一个库比如dating_db执行项目提供的dating_db.sql脚本。用Navicat或者命令行都可以。注意MySQL8的加密规则和驱动MySQL8需要com.mysql.cj.jdbc.Driver连接URL要加?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai少了时区配置会报时区异常。第三步改后端配置。在application.yml里改数据库用户名和密码spring: datasource: url: jdbc:mysql://localhost:3306/dating_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver如果你的MyBatis配置是XML形式还要检查mapper-locations配置mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.dating.entity第四步启动后端。在IDE里打开项目运行DatingApplication.java的main方法。看到Started DatingApplication就是启动成功了。我习惯把服务端口配成8080路径上下文都不加前后面对接简单。第五步启动前端。在Vue项目根目录先npm install装完依赖再npm run serve默认跑在8081端口如果8080被后端占了会自动换到8081。启动后浏览器访问http://localhost:8081登录页能打开了。如果前后端不在同一个端口需要配置跨域。我在后端config包下写了一个CorsConfig放行所有来源、所有请求头、允许携带凭证registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(*) .allowedHeaders(*) .allowCredentials(true);在开发阶段这样做没问题。上线时如果前后端分开部署我会推荐用Nginx做反向代理把/api路径转发到后端服务。这一块答辩时讲出来又是一个加分项。5.2 实测遇到的最多的三个问题以下是这个项目里我前后调试最久、也最有代表性的三个坑。问题一MyBatis的mapper接口和XML文件扫描不到。表现启动时报Invalid bound statement (not found)。原因要么XML文件放错目录了要么mapper-locations配置路径和文件实际路径不匹配。排查先看XML文件是否在src/main/resources/mapper目录下再看配置路径是否是classpath:mapper/*.xml。XML文件的namespace必须和接口全限定名一致id必须和接口方法名一致这个对应关系错一个都会报错。这里想提醒的是很多人改完配置不刷新Maven导致新加的XML文件没被拷贝到target目录看着配置对了但就是跑不起来——刷新一下Maven再重启就能解决。问题二MySQL8连接报Public Key Retrieval is not allowed。这是MySQL8的硬规则客户端连接时不允许自动获取公钥但JDBC默认又需要它。解决办法是在连接URL后面加allowPublicKeyRetrievaltruejdbc:mysql://localhost:3306/dating_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrueuseSSLfalse没加useSSLfalse在部分版本还会报一个SSL相关的warning不影响运行但看着闹心。问题三前端页面请求接口404或者405。最常见的原因是后端端口配置和前端baseURL不一致。我排查这类问题的标准流程是先在浏览器F12看Network请求确认请求的URL路径有没有拼错——前后端对接的时候路径对不上是家常便饭。前端我习惯在request.js里统一配置baseURL: http://localhost:8080/api后端Controller统一加RequestMapping(/api)两边约定好就基本上不会乱。405多半是请求方法不对后端接口是POST前端用GET调了换一下即可。5.3 调试期的高效率技巧顺手分享几个让我调试效率明显变高的技巧。Postman/Apifox维护一套完整的接口集合。写完一个接口就调通一个不要攒到联调阶段再用浏览器验证。Apifox还能导成文档写论文的系统实现章节时直接贴接口定义。SQL日志打开。在application.yml里配置mybatis.configuration.log-impl: org.apache.ibatis.logging.stdout.StdOutImpl控制台就能打印每一条SQL和参数。排查查询结果不对的场景第一件事就是看SQL到底执行了什么。热部署插件。后端加一个spring-boot-devtools依赖前端Vue本身改了代码就热更新。配合起来改完代码几秒内就能看到效果开发体验完全不一样。数据库备份打个快照。在改表结构之前用Navicat备份一下测试数据搞坏了直接恢复省去重新造数据的时间。6. 从课设到上线的扩展思路6.1 简历和面试中怎么讲这类项目这个项目做完之后简历上怎么写、面试的时候怎么讲其实是比代码本身更重要的事情。很多同学的项目经历写了三行话——使用技术、主要功能、我的职责——然后就没了面试官完全问不出东西。我建议的讲法是按业务难点-技术方案-个人思考三层结构来讲。业务难点相亲系统相对于普通管理系统核心是互相喜欢这个关系的建模以及推荐列表的个性化问题。技术方案用like_record两张关联记录配合match_record单独成表来解决互选状态管理推荐列表用基础条件过滤条件打分排序既控制查询的范围又让排序结果有业务解释力。个人思考互选判断用组合索引覆盖查询而不是应用层两次查库后比较SQL性能更好推荐打分器用Map配置权重后续调整规则不需要改代码密码用BCrypt加密而不是明文或者MD5。面试官大概率会顺着你讲的方向追问MyBatis和MyBatis-Plus你怎么选你项目的查询量多大需要考虑索引token过期了前端怎么处理这些问题如果你在写代码时真的想过就能接得住如果你只是照着网上的代码抄了一遍接不住的问题就会暴露。这个项目的技术栈和业务场景如果讲得好完全够支撑后端开发初级岗位的面试如果做深度扩展比如加Redis做缓存、加RabbitMQ做消息通知甚至可以往中高级方向聊但那是后话。6.2 可以继续做的功能方向如果后面想把这个项目做深做广我已经踩过路、知道方向上哪些是靠谱的可以按优先级排一排Redis缓存在线用户状态、未读消息数、活跃用户排名用Redis接会很自然。Redis接好后还能解决MySQL高并发查询压力性能上的改进可以写进论文的创新点。ElasticSearch全文搜索相亲网站的找对象场景天然需要按城市、学历、职业、兴趣筛选ES的倒排索引和地理位置查询都比MySQL高效得多。但ES的引入有学习成本要确认你的时间和论文篇幅是否扛得住。WebSocket实时聊天现在我的消息模块是轮询的换成WebSocket之后用户聊天体验会有质的提升而且WebSocket在SpringBoot里做服务端推送、Vue里做Socket连接技术点都很成熟值得展开。图片上传与对象存储现在头像走的是本地磁盘路径如果部署在服务器上这样太脆弱。换成MinIO或者云存储服务把头像、照片的访问域名和存储路径分开管理会专业很多。审核与安全机制相亲网站一定要有实名认证、信息审核和举报机制。就算毕设先不做也要在论文里把设计思路写进去。实名认证可以接阿里云或腾讯云的认证接口工作量不大但体现了系统的完整性和社会责任感。推荐算法升级把打分排序升级成基于用户偏好的协同过滤用用户对用户的历史行为喜欢/忽略来构建相似度矩阵。这块做出来项目从管理系统直接进化成推荐系统技术含量完全不是一个层次。6.3 最后再分享一点选题和答辩的心得我在文章最后想聊一个可能没人系统讲过的问题为什么相亲网站管理系统这个题目值得认真对待。很多学生觉得课设就是凑代码、凑论文、等答辩但一个已经做完两三遍这种项目的人会告诉你这类题目的价值不在于题目本身有多新鲜而在于它能逼你把完整的软件工程流程走一遍从需求分析到数据库设计从后端接口到前端交互从部署调试到问题排查。这段完整的闭环才是你走出校门后工作上每天都要经历的事情。相亲网站相比图书馆管理系统多了一层用户关系和业务状态流转的复杂度而恰好是这层复杂度才让你有机会在答辩和面试中说出真正属于你自己的理解。我做这个项目的整体感受是如果只是抱着下载源码往上一交的心态它会非常无聊就是填表但如果你愿意在上面花两周时间把它当成自己的作品来对待它会成为很拿得出手的Java全栈项目。最后分享一个小技巧写论文时把每个模块的核心类图、核心表结构、核心接口定义画清楚再配上为什么这样设计的两三句话答辩老师基本不会再刁难你。祝顺利。 基于SpringBoot+Vue的相亲网站管理系统设计与实现
1. 相亲网站管理系统这类Java项目到底在做什么1.1 从基本增删改查到业务闭环打开各大毕设选题列表你会发现XX管理系统占了半壁江山图书馆管理、宿舍管理、停车场管理……而基于SpringBootVue的相亲网站管理系统属于这里面比较特殊的一个。它表面上依然是标准的JavaWeb三层架构SpringBoot管后端、Vue管前端、MySQL存数据、MyBatis做ORM但业务上却比普通的单表增删改查多了一层有意思的东西——匹配、喜欢、互选、推荐。这些东西才是项目真正能和人聊出干货的地方。如果你正在准备毕业设计、课程设计或者单纯想用一套完整项目巩固SpringBootVue这套技术栈这个题目很值得做。原因有几个第一它覆盖了当前就业市场上Java后端最主流的框架组合第二它包含用户端和管理员端两套逻辑功能量足够撑起一篇论文的系统设计和系统实现章节第三它天生自带数据关系问题——一个用户喜欢谁、谁又喜欢他、两个人是否配对成功这些关系在数据库里怎么设计、在接口里怎么流转本身就是很好的面试素材。先把这个系统的功能全景摆出来。整个系统按角色分有三类使用者普通用户相亲者、管理员和系统本身。普通用户能做的事情包括注册登录、完善个人资料年龄、身高、学历、职业、收入、城市、兴趣爱好、个人介绍、浏览推荐的人选、对感兴趣的用户表达喜欢、收到喜欢通知、查看互选配对结果以及发私信、给平台留言反馈。管理员端主要是用户管理审核、禁用、删除、资料审核、反馈处理、数据统计。看到没这个功能量已经覆盖了典型管理系统该有的所有模块注册登录、个人信息维护、列表查询、详情查看、状态流转喜欢→互选、站内通信、后台管理。每一块都对应着SpringBoot里的Controller、Service、Mapper以及Vue里的页面组件和API调用。1.2 用户端和管理员端的功能矩阵我习惯在动手写代码之前先把功能矩阵画出来不然写到哪里算哪里最后肯定一堆返工。下面是这个相亲系统的完整功能拆解用户端功能注册/登录用户名密码注册登录后返回token个人资料管理基本信息增删改、头像上传、兴趣爱好标签维护推荐列表根据当前用户的条件展示推荐人选卡片用户详情查看对方完整资料发起喜欢喜欢与匹配你喜欢的列表、喜欢你的列表、配对成功的列表私信聊天配对成功后双方可以发消息个人中心修改密码、查看自己的配对记录、退出登录管理员端功能管理员登录独立账号体系和用户表分开用户管理查看所有注册用户禁用/启用账号资料审核新注册用户的资料需要管理员审核通过后才对外可见反馈管理处理用户投诉和留言数据看板注册人数、配对数量、每日活跃等统计这些功能看着多但每个都不难核心难点只有两个一是用户之间的喜欢-配对关系数据模型怎么设计二是推荐列表的条件过滤怎么实现得既简洁又实用。后面我会重点讲这两块。1.3 技术栈选型SpringBootVue为什么站得住技术选型这块老实说对于毕设和课设项目选别人都在用的主流技术栈比选我觉着很酷的冷门技术栈重要得多。为什么因为你有问题的时候能搜到答案答辩老师看着眼熟不刁难你以后简历上写出来别人也认。SpringBootSpringMVCMyBatisMySQLVueElement UI/Ant Design Vue这套组合属于Java Web领域最经典的组合拳。SpringBoot负责快速搭建项目和自动化配置SpringMVC处理HTTP请求路由MyBatis作为ORM层SQL自己控制灵活且适合讲出性能优化的故事后面我会提到MyBatis的一二级缓存怎么结合实际业务场景打开MySQL存数据Vue做单页应用配合Axios调接口。其中MyBatis是一个值得多说两句的点。它不同于JPA/Hibernate那种全自动的ORMMyBatis是半自动的SQL还是要你自己写。很多人第一次接触会觉得麻烦——明明Hibernate不写SQL挺爽的。但实际到了生产环境尤其是复杂查询、多表关联、需要手动控制SQL性能的时候MyBatis的优势非常明显。在这个相亲系统里推荐列表的查询、喜欢记录的查询都是多表关联加条件拼接用MyBatis的XML写动态SQL比在用Hibernate里拼Criteria要直观得多。而且面试时为什么用MyBatis这个问题也比为什么用JPA好回答得多我能控制SQL能针对慢查询优化能自己处理复杂关联。关于版本选择我给一个稳妥的组合SpringBoot 2.7.x别一上来就上SpringBoot 3JDK版本和部分兼容性问题能让新手折腾三天、JDK 1.8、MySQL 5.7或8.0、MyBatis 3.5.x、Vue 2.x Vue CLI或者Vue 3 Vite看你自己熟悉哪个、Element UIVue2配Element UIVue3配Element Plus。2. 数据库设计相亲业务的核心是找关系2.1 八张核心表的职责划分数据库是整个系统里最不能糊弄的部分。业务可以简单增删改查可以朴素但表结构设计得好不好直接决定你后面的代码能写多轻松。我在设计这个相亲网站的表结构时最终收敛为8张核心表。先把表列出来表名职责关键字段user用户账号表管登录id, username, password, status, created_atuser_profile用户资料表和user一对一user_id, real_name, gender, age, height, education, income, city, avatar, intro, tagsadmin管理员账号id, username, password, rolelike_record喜欢记录表id, user_id, target_id, is_matched, created_atmatch_record配对记录表id, user_one_id, user_two_id, matched_atmessage私信聊天表id, from_user_id, to_user_id, content, is_read, created_atfeedback留言反馈表id, user_id, content, reply, statusaudit_log资料审核记录表id, user_id, admin_id, action, reason, created_at这里面有两个设计上的关键决策我单独说一下。第一用户账号表和用户资料表为什么要拆开。很多新手做这种项目喜欢一张表搞定user表里又放username又放身高体重。我建议拆开原因有三一是账号信息和相亲资料信息的访问频率不一样登录只需要查user资料列表只需要查user_profile拆开能让每个查询更轻二是权限边界清晰user表里不要放手机号、真实姓名这类隐私user_profile里也不要放密码三是后面如果要扩展会员体系、实名认证加表就行不用动老表结构。第二like_record这张表的设计决定了整个匹配逻辑的复杂度。一个用户对另一个用户表达了喜欢就插一条记录user_id是主动喜欢的人target_id是被喜欢的人。当两个人互相喜欢时我们看到有(user_id1, target_id2)和(user_id2, target_id1)两条记录就是配对成功。这是最朴素也最不容易出错的互选模型。2.2 关系型数据如何支撑喜欢与配对来细看这个互选逻辑因为它是整个相亲系统的灵魂。假设用户A对用户B点了喜欢按钮后端做的事是往like_record插入一条(user_idA, target_idB)。然后立刻查一下是否存在反向记录(user_idB, target_idA)。如果不存在返回已喜欢如果存在说明是互相喜欢这时做两件事一是把两条like_record都标记为is_matched1二是在match_record里插入一条配对记录(user_one_idA, user_two_idB)。这个流程里有一个细节需要注意——判断互选时要用组合查询而不是遍历。正确SQL是SELECT id FROM like_record WHERE user_id #{targetUserId} AND target_id #{currentUserId} AND is_matched 0 LIMIT 1;查到就是互选查不到就是单向喜欢。用联合索引(user_id, target_id)覆盖这张表的查询场景速度非常快。match_record为什么单独建一张表而不是只靠like_record里的is_matched字段因为配对是用户业务上的里程碑后面会不断被查询我的配对列表、管理员的数据统计、消息通知里恭喜你们配对成功。单独成表查起来简单字段干净。而且后面要扩展解除配对功能只需要删match_record记录并更新like_record的状态不需要去翻like_record里那两条互相纠缠的记录。一个表管一个业务动作职责单一这是设计水平的一种体现。2.3 字段设计的几个关键决策字段级别有几个点值得单独拿出来说说都是我自己做过之后才意识到重要的。年龄存birthday而不是age。这是数据库设计的经典常识但也是新手最容易踩的坑。如果存age明年系统里所有人年龄都不对你总不能半夜跑个定时任务给所有用户年龄加一。存birthday查询时用TIMESTAMPDIFF(YEAR, birthday, CURDATE())计算年龄上面的问题就不存在了。性别和学历用枚举还是数字字典。用数字加字典表或者注释说明都行但不要直接存中文字符串。原因很实际第一中文占存储空间第二排序过滤不方便第三前后端可以通过字典映射成统一的中文显示。我习惯用tinyint性别1男2女学历1高中2大专3本科4硕士5博士数据库里加注释后端枚举类管理。text字段慎用。个人简介、职业经历这种可能很长的内容用text没问题。但一个典型的误区是把所有varchar都设成255的长度——数据库的varchar虽然灵活但设置过短会导致数据丢不了也存不下设置过长又会影响索引效率。我一般是名称、城市、学历这类字段varchar(50)头像URL、用户名varchar(100)个人简介text。所有表都要有create_time和update_time。这不是废话。管理后台的数据统计、测试阶段的排查问题、面试时谈我从审计日志里发现……的案例都靠这些时间字段。MyBatis里用insert和update时手动NOW()就行别嫌麻烦。avatar不要直接存图片文件存URL路径。图片文件上传到服务器的upload目录数据库里只存访问路径。这个设计好处是数据库体积可控、分布式部署时可以把图片迁移到对象存储。用户状态status要有软删除意识。用户可能被管理员禁用也可能自己要注销。不要在表里直接DELETE用一个status字段控制0禁用 1正常。这样数据可追溯测试和恢复都方便。索引方面除了每张表的主键索引我还会在下面几个位置建立索引like_record(user_id, target_id)组合查询互选时走这个索引。match_record(user_one_id, user_two_id)查个人配对记录走这个索引。user_profile(gender, city)推荐列表按性别城市过滤时走这个索引。还有如果你的MySQL版本是8.0可以考虑在user_profile.city字段上建一个普通索引就行不用建组合索引的必要因为推荐列表通常还需要按年龄排序而年龄是计算出来不是直接存的后面我会说这个查询怎么处理。3. 后端实现登录鉴权、匹配推荐与服务端接口3.1 项目工程结构与统一响应体后端工程结构我按主流方式组织目录清晰答辩时也好讲src/main/java/com.example.dating/ ├── config跨域配置、拦截器配置 ├── controllerREST API层 ├── service业务逻辑层 ├── mapperMyBatis数据访问层 ├── entity数据库实体类 ├── common统一返回体、异常处理、常量 ├── utilJWT工具类、加密工具类 └── DatingApplication.java代码写之前先把统一返回体定义了。为什么要统一前端Axios拦截器需要统一判断返回状态后端每个接口都返回自己的结构会让前端处理起来像噩梦。统一返回体长这样public class ResultT { private Integer code; // 200成功其他失败 private String message; // 提示信息 private T data; // 数据 public static T ResultT success(T data) { ... } public static T ResultT error(String message) { ... } }加上一个全局异常处理器用RestControllerAdvice捕获Service层抛出的业务异常转换成统一返回体。这些是SpringBoot开发的基础素养写进项目里会让整体代码质量看起来高一个档次。3.2 登录鉴权与密码存储的安全底线登录鉴权我用JWT理由很直接无状态、好扩展、社区资料多。用户在登录接口提交username和passwordService层先用userMapper.findByUsername(username)查出账号比对密码成功则生成一个token返回前端前端存到localStorage之后每次请求在Authorization头带上token后端拦截器解析token得到当前用户ID。// 登录逻辑核心代码 public LoginResponse login(String username, String password) { User user userMapper.findByUsername(username); if (user null) { throw new BusinessException(用户名或密码错误); } if (!BCrypt.checkpw(password, user.getPassword())) { throw new BusinessException(用户名或密码错误); } if (user.getStatus() 0) { throw new BusinessException(账号已被禁用请联系管理员); } String token JwtUtil.generateToken(user.getId(), user.getUsername()); return new LoginResponse(token, user.getId()); }这里我特别强调一点密码存储不要用MD5不要用SHA至少用BCrypt加盐加密。我知道很多毕设项目都是老代码模板复制的密码全是MD5。但在2025年这个时间点你简历上写着我对密码做了MD5加密是会直接被面试官扣分的MD5撞库破解已经很容易BCrypt加盐后暴力破解成本极高。Spring Security crypto工具包里直接有BCrypt实现引入一个依赖就行代码就一行BCrypt.hashpw(password, BCrypt.gensalt())。成本几乎为零收益是安全底线的达标。JWT的密钥要放在application.yml里别硬编码在代码里。过期时间我设置7天因为相亲网站用户没事不会天天来太短要频繁登录太长token泄露风险大。3.3 推荐算法不是随机捞几条那么简单推荐列表这个功能表面上是个列表查询但做得好不好直接关系到这个项目答辩时你是有东西讲还是只能背代码。我的实现思路分三档由浅入深第一档是基础条件过滤。查询user_profile时过滤掉性别相同的、过滤掉自己、过滤掉已经喜欢的防止重复推荐、过滤掉资料未审核的。SQL大致是SELECT p.* FROM user_profile p LEFT JOIN like_record l ON l.user_id #{currentUserId} AND l.target_id p.user_id WHERE p.gender ! #{myGender} AND p.status 1 AND l.id IS NULL ORDER BY p.user_id DESC LIMIT #{offset}, #{pageSize}第二档是加排序权重。条件过滤太冰冷了用户看到的结果是没头没尾的。可以按用户自身填写的理想对象要求来打分年龄范围匹配加多少分、城市一致加多少分、学历不低于要求加多少分、兴趣爱好有重叠加多少分。在Java里写一个打分器或者干脆在SQL里用CASE WHEN做分数计算。第三档是加入活跃度和时间衰减。新注册用户优先展示最近登录活跃的用户优先展示。这个在毕设里可以用ORDER BY里加字段实现真正生产上会用Redis的ZSet做但毕设阶段不用那么复杂。我的建议是做到第二档就很好了代码实现不复杂但是能讲清楚为什么不同用户看到的结果是不同的。public ListUserProfileVO recommendList(Integer currentUserId, int page, int pageSize) { // 1. 查当前用户资料用于过滤和打分 UserProfile myProfile userProfileMapper.findByUserId(currentUserId); // 2. 基础过滤性别相反、状态正常、未审核通过、未喜欢过 ListUserProfile candidates userProfileMapper.findCandidates( myProfile.getGender().equals(1) ? 2 : 1, currentUserId, page, pageSize); // 3. 打分排序 return candidates.stream() .map(profile - toVO(profile, computeScore(myProfile, profile))) .sorted((a, b) - b.getScore() - a.getScore()) .collect(Collectors.toList()); }打分器的规则用Map配置好每个条件一个权重城市相同30分年龄在期望范围内25分学历不低于期望20分兴趣爱好交集≥2个15分这样推荐列表排出来就有逻辑了答辩时老师问你的推荐策略是什么你就能从规则打分和排序讲到数据智能延展性很强。3.4 喜欢、互配、私信的接口逻辑喜欢接口是另一个核心。我在前面第2章讲过表设计这里把完整的Service逻辑贴出来Transactional public MatchResult likeUser(Long currentUserId, Long targetUserId) { // 1. 不能喜欢自己 if (currentUserId.equals(targetUserId)) { throw new BusinessException(不能对自己表达喜欢); } // 2. 不能重复喜欢 if (likeRecordMapper.exists(currentUserId, targetUserId)) { throw new BusinessException(你已经喜欢过对方了); } // 3. 插入喜欢记录 likeRecordMapper.insert(new LikeRecord(currentUserId, targetUserId)); // 4. 查对方是否喜欢了自己 LikeRecord reverse likeRecordMapper.findReverse(targetUserId, currentUserId); if (reverse ! null) { // 互选成功更新状态 插配对记录 likeRecordMapper.markMatched(currentUserId, targetUserId); likeRecordMapper.markMatched(targetUserId, currentUserId); matchRecordMapper.insert(new MatchRecord(currentUserId, targetUserId)); return MatchResult.MATCHED; } return MatchResult.LIKED; }这里有个细节要注意用了Transactional。因为插喜欢记录和更新互选状态是对应着同一个业务事件的两个数据库操作要么都成功要么都不成功不能用事务的各管各的。私信模块我做的相对克制——配对成功后才能发消息非配对状态发私信在接口层直接拦截。这样做有几个好处一是业务逻辑上符合相亲场景你都不喜欢人家凭什么骚扰人家二是避免消息表被垃圾数据灌爆。前端聊天界面轮询接口获取新消息实现即时性足够用了如果要做得更好可以在后面扩展WebSocket这个我在第6章会提。4. Vue前端从页面到交互4.1 前端项目结构与路由设计前端我建议直接用Vue CLI或者Vite初始化一个脚手架项目目录结构按views组件化的方式来src/ ├── api/axios封装 各模块接口定义 ├── router/路由配置 ├── store/Vuex或Pinia存登录状态 ├── views/页面组件 │ ├── Login.vue │ ├── Home.vue推荐列表 │ ├── ProfileDetail.vue用户详情 │ ├── MatchList.vue配对列表 │ ├── Message.vue私信聊天 │ ├── Personal.vue个人中心 │ └── admin/管理员相关页面 ├── utils/工具类 └── App.vue路由的精心设计之处在于路由守卫这是Vue前端拦截器中能不能控制访问权限的关键// router/index.js router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { next(/login); } else { next(); } })凡是需要登录才能访问的页面路由meta标记requiresAuth: true未登录状态直接踢到登录页。这个实现五步就能讲完但它是整个前端安全访问控制的核心答辩时属于为什么这样的设计的好问题。4.2 核心页面推荐列表、用户详情、个人中心推荐列表页面是整个用户端的门面。我用的是卡片流布局每个卡片展示头像、昵称、年龄、城市、一句签名右下角一个喜欢按钮。页面加载时调用/api/recommend接口拿到推荐列表数据渲染到卡片网格里。这个页面的两个开发细节需要特意说第一个Axios请求拦截器统一带token。我没在每个请求方法里手动加token而是在request.js里统一拦截service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] Bearer ${token}; } return config; });第二个喜欢按钮的即时反馈。用户点了喜欢按钮立刻变成已喜欢并置灰避免重复点击。这里的接口返回如果包含MATCHED状态那就弹出成功提示恭喜你们匹配成功去发消息吧并更新配对列表数据。用户在这个环节的体验快感是用户留存的关键。用户详情页展示完整资料基本资料、学历职业、兴趣爱好标签、个人简介。资料展示完了页面最显眼的位置还是喜欢TA按钮和推荐卡片的逻辑打通。这里要特别注意详情页里不要展示对方手机号、微信号等联系方式一是隐私保护的需要二是鼓励用户通过平台私信交流这正是相亲平台存在的意义。个人中心页就是我的资料、我的喜欢、喜欢我的、我的配对、修改密码这些入口。其中喜欢我的列表特别能拉用户回来一条条有人对你心动了的通知比任何运营活动都有效。所以我在个人中心设计了一个未读消息数量和喜欢数量的小红点逻辑。4.3 后台管理页面的表格化实现管理员的页面我用Element UI的el-table组件来做这是后台管理系统最典型的形态。用户管理表格展示ID、用户名、姓名、性别、年龄、城市、学历、状态、注册时间、操作。操作列里有禁用/启用和查看详情两个按钮。禁用调用后端接口修改user.status前端表格刷新。这里有个交互上的注意点禁用之后该用户的所有点赞、配对操作后端都要拒绝——不是前端按钮灰不灰的问题是后端接口要做状态校验。我在后端的拦截器里加了校验逻辑token解析出用户ID后先查一下status为0直接返回账号已被禁用。数据看板页面我用el-card加几个大数字展示注册用户总数、配对成功总数、今日新增用户、今日配对数量。这些数据的SQL都是简单的COUNT(*)查询。如果想让这个页面看起来更高级可以用ECharts画一个最近7天注册趋势的折线图半小时能搞定但界面效果提升一个档次。毕设文档里也多一张功能截图可以说。5. 完整启动步骤与踩坑记录5.1 从零到运行数据库初始化、后端启动、前端启动这节写给第一次跑这类项目的同学。很多人项目代码有了本地环境起不来半天时间耗在环境配置上非常耽误事。下面是我实测下来最顺的流程。第一步准备环境。装好JDK 1.8、Maven 3.6、MySQL 5.7或8.0、Node.js 14Vue2或16Vue3。检查mvn -v、node -v、mysql --version都能输出版本号。第二步初始化数据库。在MySQL里创建一个库比如dating_db执行项目提供的dating_db.sql脚本。用Navicat或者命令行都可以。注意MySQL8的加密规则和驱动MySQL8需要com.mysql.cj.jdbc.Driver连接URL要加?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai少了时区配置会报时区异常。第三步改后端配置。在application.yml里改数据库用户名和密码spring: datasource: url: jdbc:mysql://localhost:3306/dating_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver如果你的MyBatis配置是XML形式还要检查mapper-locations配置mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.dating.entity第四步启动后端。在IDE里打开项目运行DatingApplication.java的main方法。看到Started DatingApplication就是启动成功了。我习惯把服务端口配成8080路径上下文都不加前后面对接简单。第五步启动前端。在Vue项目根目录先npm install装完依赖再npm run serve默认跑在8081端口如果8080被后端占了会自动换到8081。启动后浏览器访问http://localhost:8081登录页能打开了。如果前后端不在同一个端口需要配置跨域。我在后端config包下写了一个CorsConfig放行所有来源、所有请求头、允许携带凭证registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(*) .allowedHeaders(*) .allowCredentials(true);在开发阶段这样做没问题。上线时如果前后端分开部署我会推荐用Nginx做反向代理把/api路径转发到后端服务。这一块答辩时讲出来又是一个加分项。5.2 实测遇到的最多的三个问题以下是这个项目里我前后调试最久、也最有代表性的三个坑。问题一MyBatis的mapper接口和XML文件扫描不到。表现启动时报Invalid bound statement (not found)。原因要么XML文件放错目录了要么mapper-locations配置路径和文件实际路径不匹配。排查先看XML文件是否在src/main/resources/mapper目录下再看配置路径是否是classpath:mapper/*.xml。XML文件的namespace必须和接口全限定名一致id必须和接口方法名一致这个对应关系错一个都会报错。这里想提醒的是很多人改完配置不刷新Maven导致新加的XML文件没被拷贝到target目录看着配置对了但就是跑不起来——刷新一下Maven再重启就能解决。问题二MySQL8连接报Public Key Retrieval is not allowed。这是MySQL8的硬规则客户端连接时不允许自动获取公钥但JDBC默认又需要它。解决办法是在连接URL后面加allowPublicKeyRetrievaltruejdbc:mysql://localhost:3306/dating_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrueuseSSLfalse没加useSSLfalse在部分版本还会报一个SSL相关的warning不影响运行但看着闹心。问题三前端页面请求接口404或者405。最常见的原因是后端端口配置和前端baseURL不一致。我排查这类问题的标准流程是先在浏览器F12看Network请求确认请求的URL路径有没有拼错——前后端对接的时候路径对不上是家常便饭。前端我习惯在request.js里统一配置baseURL: http://localhost:8080/api后端Controller统一加RequestMapping(/api)两边约定好就基本上不会乱。405多半是请求方法不对后端接口是POST前端用GET调了换一下即可。5.3 调试期的高效率技巧顺手分享几个让我调试效率明显变高的技巧。Postman/Apifox维护一套完整的接口集合。写完一个接口就调通一个不要攒到联调阶段再用浏览器验证。Apifox还能导成文档写论文的系统实现章节时直接贴接口定义。SQL日志打开。在application.yml里配置mybatis.configuration.log-impl: org.apache.ibatis.logging.stdout.StdOutImpl控制台就能打印每一条SQL和参数。排查查询结果不对的场景第一件事就是看SQL到底执行了什么。热部署插件。后端加一个spring-boot-devtools依赖前端Vue本身改了代码就热更新。配合起来改完代码几秒内就能看到效果开发体验完全不一样。数据库备份打个快照。在改表结构之前用Navicat备份一下测试数据搞坏了直接恢复省去重新造数据的时间。6. 从课设到上线的扩展思路6.1 简历和面试中怎么讲这类项目这个项目做完之后简历上怎么写、面试的时候怎么讲其实是比代码本身更重要的事情。很多同学的项目经历写了三行话——使用技术、主要功能、我的职责——然后就没了面试官完全问不出东西。我建议的讲法是按业务难点-技术方案-个人思考三层结构来讲。业务难点相亲系统相对于普通管理系统核心是互相喜欢这个关系的建模以及推荐列表的个性化问题。技术方案用like_record两张关联记录配合match_record单独成表来解决互选状态管理推荐列表用基础条件过滤条件打分排序既控制查询的范围又让排序结果有业务解释力。个人思考互选判断用组合索引覆盖查询而不是应用层两次查库后比较SQL性能更好推荐打分器用Map配置权重后续调整规则不需要改代码密码用BCrypt加密而不是明文或者MD5。面试官大概率会顺着你讲的方向追问MyBatis和MyBatis-Plus你怎么选你项目的查询量多大需要考虑索引token过期了前端怎么处理这些问题如果你在写代码时真的想过就能接得住如果你只是照着网上的代码抄了一遍接不住的问题就会暴露。这个项目的技术栈和业务场景如果讲得好完全够支撑后端开发初级岗位的面试如果做深度扩展比如加Redis做缓存、加RabbitMQ做消息通知甚至可以往中高级方向聊但那是后话。6.2 可以继续做的功能方向如果后面想把这个项目做深做广我已经踩过路、知道方向上哪些是靠谱的可以按优先级排一排Redis缓存在线用户状态、未读消息数、活跃用户排名用Redis接会很自然。Redis接好后还能解决MySQL高并发查询压力性能上的改进可以写进论文的创新点。ElasticSearch全文搜索相亲网站的找对象场景天然需要按城市、学历、职业、兴趣筛选ES的倒排索引和地理位置查询都比MySQL高效得多。但ES的引入有学习成本要确认你的时间和论文篇幅是否扛得住。WebSocket实时聊天现在我的消息模块是轮询的换成WebSocket之后用户聊天体验会有质的提升而且WebSocket在SpringBoot里做服务端推送、Vue里做Socket连接技术点都很成熟值得展开。图片上传与对象存储现在头像走的是本地磁盘路径如果部署在服务器上这样太脆弱。换成MinIO或者云存储服务把头像、照片的访问域名和存储路径分开管理会专业很多。审核与安全机制相亲网站一定要有实名认证、信息审核和举报机制。就算毕设先不做也要在论文里把设计思路写进去。实名认证可以接阿里云或腾讯云的认证接口工作量不大但体现了系统的完整性和社会责任感。推荐算法升级把打分排序升级成基于用户偏好的协同过滤用用户对用户的历史行为喜欢/忽略来构建相似度矩阵。这块做出来项目从管理系统直接进化成推荐系统技术含量完全不是一个层次。6.3 最后再分享一点选题和答辩的心得我在文章最后想聊一个可能没人系统讲过的问题为什么相亲网站管理系统这个题目值得认真对待。很多学生觉得课设就是凑代码、凑论文、等答辩但一个已经做完两三遍这种项目的人会告诉你这类题目的价值不在于题目本身有多新鲜而在于它能逼你把完整的软件工程流程走一遍从需求分析到数据库设计从后端接口到前端交互从部署调试到问题排查。这段完整的闭环才是你走出校门后工作上每天都要经历的事情。相亲网站相比图书馆管理系统多了一层用户关系和业务状态流转的复杂度而恰好是这层复杂度才让你有机会在答辩和面试中说出真正属于你自己的理解。我做这个项目的整体感受是如果只是抱着下载源码往上一交的心态它会非常无聊就是填表但如果你愿意在上面花两周时间把它当成自己的作品来对待它会成为很拿得出手的Java全栈项目。最后分享一个小技巧写论文时把每个模块的核心类图、核心表结构、核心接口定义画清楚再配上为什么这样设计的两三句话答辩老师基本不会再刁难你。祝顺利。