基于SpringBoot2+Vue3的相亲网站全栈开发实战

1. 需求拆解相亲网站到底在做什么1.1 先别急着写代码把择偶条件拆清楚拿到基于SpringBoot2Vue3的相亲网站这个题目的时候我的第一反应不是急着建工程而是把一个现实问题想明白相亲网站和普通社交软件最大的区别是什么答案是它更像一套结构化的条件匹配系统。用户上来第一件事不是看看附近的人而是填年龄、身高、学历、收入、房车情况。如果你把用户表随便建成用户名、手机号、头像、昵称、个性签名后面产品说要支持年收入5万以下屏蔽身高165以上优先推荐你就得改表、加字段、写迁移脚本前端表单也要返工。这个教训我吃过一次之后立了一个规矩凡是筛选条件里可能出现的基础属性全部设计成独立字段而不是塞进一个JSON里。具体来说我把资料拆成了几个区块基础信息性别、出生日期、身高、体重、婚姻状况、子女情况、教育与职业学历、职业类型、单位性质、年收入区间、工作城市、生活环境房、车、是否接受共同还贷、家庭背景籍贯、父母情况、兄弟姐妹、生活方式性格、作息、烟酒、运动频率、兴趣爱好、择偶偏好对方的年龄范围、身高范围、学历下限、城市、婚姻状况接受度。注意这里有个很容易忽略的点很多需求文档只写了展示用户的征友资料没写搜索条件但搜索条件恰恰是从个人偏好延伸出来的。所以我单独建了一张preference表存择偶偏好这样用户搜索时可以直接拿自己填的偏好当默认筛选条件体验非常自然。1.2 先做功能闭环推荐、互动、审核、会员相亲网站的业务不像博客或者商城那样一条线性链路它是一张环环相扣的网。我梳理的时候把功能分成了五个模块最后确定核心闭环是这样的用户注册登录完善征友资料和择偶偏好账号激活系统每日推荐候选人双方互相喜欢配对成功发起打招呼或私信在线聊天申请交换联系方式这个闭环里最容易被忽略但特别影响体验的是互相喜欢这个中间态。很多人做相亲项目只做了单方面送花/打招呼结果用户根本没有被需要的正反馈留存很差。所以我加了喜欢和喜欢我的双向操作你今天喜欢的用户对方能看到你的来访记录和喜欢状态如果对方也点了喜欢就触发配对成功提示这时候才允许双方直接发私信。这个逻辑在数据上就是一个match_record表状态位分别是0单方喜欢、1互相喜欢、-1取消。除了用户端管理后台也是必须的。相亲平台天然要面对虚假信息、照片审核、言语骚扰这些运营问题。后台至少要有三个页面用户管理列表、详情、封禁、解封、会员设置、内容审核照片和动态的过审/驳回、举报处理查看举报原因、处理结果。这些页面顺手就配套上RBAC权限管理员、审核员、普通运营各角色权限不同项目答辩或者面试评讲时这块儿足够讲清楚权限模型怎么设计。1.3 用户角色与状态机的边界一开始很容易把用户状态做成简单的正常/封禁两个值其实不够。我建议至少保留这些状态未激活注册了没填完资料、正常、待审核上传了证件或真人认证、封禁、注销。每个状态决定了接口层面能否执行搜索、喜欢、私信操作。举个例子未激活用户能浏览推荐列表但要点喜欢按钮时后端要拦住并提示去完善资料。这种状态机设计能避免前端做一堆if判断后端一个网关层拦截就解决。至于角色我用角色表和用户角色关联表实现没有把角色字段直接硬编码在user表。虽然小项目看起来多余但管理端未来可能增加红娘角色——能代会员搜索并推荐符合条件的用户权限边界又不一样。有了这套RBAC基础扩角色只需要加一条记录和一个路由配置不用动逻辑代码。2. 技术选型SpringBoot2 Vue3 的组合逻辑2.1 为什么项目仍然用 SpringBoot2而不是无脑上 SpringBoot3这两年SpringBoot3 JDK17被讲得太多了网上教程一搜一大把。但真实业务里很多公司、很多毕业设计课题都指定SpringBoot2不是因为它落后而是因为生态稳定、历史资源多、踩坑答案全。SpringBoot2.x的长期支持版本是2.7.x配合JDK8的适配性是所有版本里最顺滑的。我们做相亲网站这种中台项目用到的核心组件还是Web、MyBatis-Plus、Redis、JWT、WebSocket这一套SpringBoot2完全够用而且配套文档、博客、GitHub issue非常多。真遇到问题一搜基本能查到前人的解决方案。另外如果团队里还有别的老系统要做对接SpringBoot2的兼容面明显更宽尤其是某些公司还在用旧版Spring Cloud体系时强行上3.0会踩一堆治理组件的兼容坑。所以我给这个项目的定版是SpringBoot 2.7.18 JDK8 Maven 3.8引入的依赖全部锁版本比如MyBatis-Plus 3.5.x、JWT的java-jwt 3.x。这里强调锁版本非常重要Java生态的依赖升级经常连带兼容问题比如jjwt 0.9.1在JDK8下要用javax.xml.bind否则会报ClassNotFoundException。很多新手直接被这个卡住原因就是没有锁版本一路next一路报错。2.2 前端为什么选 Vue3 Vite Pinia Element PlusVue3现在已经不是新框架了是事实上的主流。选Vue3的原因很明确Composition API逻辑复用方便script setup写法让组件代码更紧凑性能上也比Vue2提升不少。搭配Vite做开发服务器冷启动秒级响应改代码热更新也是毫秒级开发体验比Webpack时代舒服太多。状态管理我用了Pinia而不是Vuex。Pinia天然支持TypeScript写法上就是定义store、暴露state和action组件里直接用不需要写一堆mutation的模板代码。以登录态为例我在store里放userInfo、token、isAdmin三个状态登录接口成功后统一写入localStorage和Pinia路由刷新后再初始化这套流程比Vuex时代省很多心思。UI组件库选择Element Plus主要是它跟Vue3的兼容性好、后台表单组件齐全。像资料编辑页的表单、筛选栏的下拉选、管理后台的表格分页Element Plus都有现成组件。相亲网站的用户端不像电商那样要特别炫的视觉设计Element Plus默认风格干净小调整一下间距和主色就能看。2.3 辅助组件与服务Redis、OSS、WebSocket 怎么选选辅助组件时不要为了技术亮点硬塞一堆中间件。我参考的实际项目经验是能用Redis解决的问题绝不引入另一个重服务。Redis在这里承担三件事。第一验证码和短信验证码的存储设置5分钟过期。第二每日推荐列表的缓存因为推荐列表涉及多次联表查询直接缓存一份JSON用户刷新时直接拿节省数据库压力。第三登录状态可以用JWT无状态化但封禁用户这种需要即时生效的变更可以通过Redis存黑名单来实现比改JWT有效期灵活。文件上传我建议优先走云OSS比如阿里云OSS或腾讯云COS因为磁盘存储会占用应用服务器空间而且部署上线时文件迁移麻烦。如果条件不允许走云存储本地用MinIO搭一个对象存储服务也完全可以接口上把上传结果统一返回URL前端拿到URL直接展示。相亲网站的照片是需要审核的所以上传之后要进pending状态管理员审核通过才能公开。实时聊天我用了SpringBoot自带的WebSocket没有额外上Netty。用户量级在几千到几万时单机WebSocket完全够用。前端用原生WebSocket封装一个消息管理器断线自动重连、心跳保活消息发送成功后追加本地消息列表。会员离线时消息落库并在登录后拉取未读列表这里就是经典的在线走Socket、离线走接口双通道方案。3. 数据库设计相亲系统的地基怎么打3.1 核心表结构与字段取舍我把核心表拆成八张听起来不多但每张表字段都经过业务校验表名作用核心字段user账号主表phone、password、status、role_iduser_profile征友资料主表user_id、gender、birth_date、height、education、annual_income、city、house、caruser_preference择偶偏好表age_min、age_max、height_min、education_min、city、marital_statusphoto相册表user_id、url、is_cover、statusmatch_record喜欢/互相喜欢记录from_user_id、to_user_id、statusmessage私信记录表from_user_id、to_user_id、content、read_statusreport举报表report_user_id、target_user_id、reason、statusadmin_user后台管理员表username、password、role刻意没建会员订单表因为那个涉及支付毕业设计或演示阶段可以做成配置灵活的会员套餐接口真金白银支付环节简化掉。有一张表可能更容易被忽略字典表。城市、职业、学历、收入区间这些字段建议统一存数字编码页面显示文案从字典表读。这么做的好处是产品改选项时不用发版后台改配置就行坏处是查询时要join字典表或者前端做一次映射开发前期稍麻烦一点但维护收益明显。3.2 索引、冗余字段和查询优化相亲网站上最频繁的SQL是什么是筛选搜索。条件可能同时出现性别、年龄范围、城市、学历、身高、年薪、是否有房有车。这种组合条件查询最怕的就是表里没有合适索引又或者前端一筛选就是一次全表扫描。我的做法是三管齐下。第一针对高频过滤字段建立联合索引比如gender, city, age就是一组典型场景因为平台内用户多数在同城范围内筛选。第二对身高、年收入、学历这类区间字段在表里存的是数字编码而不是文本描述。学历用1、2、3、4、5对应从高中到博士收入用区间编号0-5这样SQL里直接大于等于某个编号就能筛排序也方便。第三把是否推荐这类运营标记和业务查询字段分开比如首页推荐列表用recommend_score综合资料完整度、活跃度、会员等级算出来的数值排序避免每次用一堆条件实时计算。还要注意一个坑不要把年龄存成数字。用户会老每年要批量更新代价很大。正确的做法是存birth_date出生日期查询时用当前时间动态计算年龄范围。这个设计在相亲项目里算常见考点如果答的是存年龄字段会减分。3.3 照片与资料审核的数据流转照片为什么要单独建表因为一个用户有多张照片还要区分封面、审核状态。上传接口上传后生成记录photo.status默认0待审核管理后台审核通过改成1用户端查询只返回status1的公开照片。资料审核同理。用户首次填写资料提交后user_profile.status进入待审核审核通过后用户才能被搜索到。有人问这样会不会太慢影响用户注册转化率业务上可以通过提示语、自动审核比如只对接实名认证接口自动通过来平衡。技术上我们要做的是把资料内容和资料审核状态解耦内容在profile表审核结果在单独的audit_log表这样即使信息更新也不用改动主表结构。4. 后端实现推荐、匹配、聊天这三块硬骨头4.1 推荐算法的取舍不做协同过滤先做条件加权打分相亲网站的推荐和电商推荐不一样电商可以用协同过滤因为用户行为多、物品多相亲平台用户行为稀疏刚注册的推荐尤其依赖先匹配条件再说了。我的推荐逻辑是拿当前用户的择偶偏好表做过滤条件把候选集中符合条件的用户筛出来再按一个加权打分函数排序。打分公式大致是score 条件匹配度 * 0.6 资料完整度 * 0.2 活跃度 * 0.1 会员权重 * 0.1条件匹配度这里不是简单的是否符合而是有梯度的比如对方年龄在偏好范围内得分1.0超出偏好范围1-2岁得分0.6再远一点得分0.3。身高同理。最后所有条件得分加权求和再映射成百分制。这个算法在MySQL里怎么落地我写成两步第一步用where条件把明显不符合的过滤掉性别、婚姻状况、年龄硬区间第二步用计算好的打分字段和活跃度字段排序LIMIT一页。用户量涨到百万级后这个查询会变重届时再上Elasticsearch或者把候选人预计算进Redis。但作为SpringBoot2Vue3的中型项目引入Elasticsearch只会徒增复杂度不是现阶段最优解。4.2 JWT鉴权与权限拦截器设计JWT在相亲项目里的用法跟普通后台差不多但有两个细节要特殊处理一是游客浏览权限二是封禁用户即时失效。我在后端定义了一个拦截器拦截所有非登录接口但放行几个白名单路径/api/auth/login、/api/auth/register、/api/auth/sms、/api/user/public/*用于游客浏览公开资料。登录成功后返回一个自定义token携带userId、role、expireTime。拦截器里先校验签名再从Redis查一下这个userId是否在黑名单如果在就直接拒绝这样能实现封禁即时生效。权限上除了登录拦截我单独做了一个RequireRole注解用在管理端接口上。AOP实现取当前用户角色再跟注解要求的角色列表比较不匹配返回403。这样管理员、审核员、普通用户三类接口的权限边界非常清楚。4.3 WebSocket私信在线走通道离线存消息聊天是相亲网站最容易出问题的一环。我见过不少同学直接前端轮询接口每5秒请求一次未读消息这种做法在小规模演示没问题但谈谈面试或者压测就露怯了。我用的方案是SpringBoot的WebSocket原生实现。用户登录后前端建立ws连接地址带上token参数。连接打开时我把userId和WebSocketSession做绑定存到一个本地ConcurrentHashMap里。收到消息时先判断目标是否在线在线则直接通过session发送不在线则只存数据库等对方上线后再推送你有未读消息的通知。这里有个单机方案的局限性如果以后要多机部署本地Map就失效了。所以代码里我封装了一个SessionManager接口现在实现是本地Map未来要扩展成Redis发布订阅或者引入消息中间件也不会推翻重来。这个设计在代码评审时很有说服力。5. 前端落地从登录页到管理后台的工程化实现5.1 路由、登录态与页面骨架前端工程我用Vite脚手架初始化选择Vue3 TypeScript模板。很多人觉得TypeScript写起来费劲但维护这个项目你会发现资料字段那么多天天在改数据结构TS能拦截掉一大批低级错误。路由设计上用户端和管理端走两个layout用户端是LayUser包含底部的推荐、喜欢、消息、我的四个Tab管理端是LayAdmin左侧菜单、顶栏、内容区。路由守卫统一在前置守卫里判断token有token才允许进入需要登录的页面用户端和管理端的路由在meta里标了roles不符合角色的直接跳登录。登录态的持久化用Pinia管理。Pinia初始化时从localStorage读tokenstore的getter判断isLoggedIn。但要注意localStorage里的token如果过期前端不能自己判断所以要做一个全局响应拦截axios所有请求如果返回401清理本地登录态并跳转登录页同时用ElMessage提示登录已过期请重新登录。5.2 资料填写页与筛选搜索页的组件设计资料填写这个页面简直是表单地狱。二十多个字段如果全放在一个form里用户填崩溃产品也扛不住。我拆成四步向导第一步基础信息第二步教育职业与生活环境第三步生活方式与兴趣爱好第四步择偶偏好。每一步用Element Plus的el-steps展示进度最后统一提交。这里一个编码细节所有下拉选项统一走字典配置接口。学历、收入区间、职业类型、城市列表都是从后端字典表读的前端不硬编码。这样产品改选项时不用发版后台改配置就行。搜索页就相对简单了左边筛选项右边推荐卡片列表筛选条件变化时防抖请求接口通常设300毫秒。5.3 推荐卡片与喜欢交互的性能优化用户端首页推荐列表一般一次加载20条卡片上要展示头像、昵称、年龄、身高、学历、职业、年收入还要显示已认证这种标识。卡片多、图片多最容易犯的错是图片不懒加载导致首屏全是图片请求。Element Plus的el-image自带懒加载我用它统一替换img标签。列表用v-infinite-scroll做无限滚动滑到底部自动拉下一页。点赞按钮要有点击反馈点之前先本地更新样式防止用户手快连点两次同时后端接口做好幂等同一条match_record存在时直接返回成功而不是报错。5.4 浏览器兼容的边角问题Vue3项目有时候在Edge浏览器里会出现一些莫名其妙的现象比如浏览器窗口右上角的最小化按钮偶尔失灵看着很玄实际排查下来往往是页面里某个全局监听事件出了问题。我遇到过一例页面里用了window.addEventListener(keydown)监听回车键但是组件销毁时没移除监听导致事件泄漏Edge渲染进程卡住连浏览器窗口的默认行为都被影响。所以代码里凡是全局事件监听一定要在onUnmounted里removeEventListener或者用第三方库时检查它是否自带清理。至于某些Vue3 TS项目在若依这类脚手架上报ts类型错误大部分情况不是框架问题而是依赖版本冲突。比如vue-tsc版本和Vue版本不一致或者严格模式下Element Plus的类型导入路径不对。我处理这类问题的通用套路是先升级依赖到兼容版本再把类型报错的地方用DefineComponent或类型断言临时兼容最后解决根因。实在急就直接把vue-tsc从构建流程里去掉构建时只跑vite build这个方案虽然不完美但很实用。6. 常见问题与排查技巧实录6.1 跨域问题前后端分离项目跨域错误是最常见的启动期问题。前端8080端口后端8081端口浏览器直接拦截。解决办法是后端配一个CorsFilter或在SpringSecurity配置里放行指定origins。但要注意如果用了自定义JWT拦截器CORS配置和拦截器的执行顺序很关键CORS要先于拦截器处理OPTIONS预检请求否则预检请求会被拦截器拦掉前端照样报跨域。我通常这样写Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(http://localhost:*, http://127.0.0.1:*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里注意使用allowedOriginPatterns而不是allowedOrigins配合allowCredentials(true)时不会抛异常。前端代理方式也能解决但上线部署后还是要后端真正处理所以后端配置是必须的。6.2 文件上传后无法回显上传接口返回了URL但页面里图片403或404。十有八九是三种原因一是前后端端口不同图片URL是相对路径如/upload/xxx.jpg但前端在8080请求就打到了前端服务器二是云OSS的私有读权限没配公开读权限也没开三是本地路径写错application.yml里的upload-path和静态资源映射路径不一致。我用本地存储时的方案是把上传目录配成应用外绝对路径再用WebMvcConfigurer映射成虚拟路径app: upload-path: /data/app/upload/registry.addResourceHandler(/upload/**) .addResourceLocations(file: appConfig.getUploadPath());这样URL统一是/upload/xxx.jpg后端静态资源映射到真实磁盘目录前端拼接域名直接访问。6.3 Token过期、并发登录这类登录态问题用户A登录过期后前端连续点了多个接口会同时收到好几个401触发多次跳登录页和刷新token的请求。我建议在axios响应拦截器里加一个正在刷新token的锁let isRefreshing false let pendingQueue [] service.interceptors.response.use( (response) response, async (error) { const { response, config } error if (response response.status 401) { // 刷新token逻辑刷新期间把其他401请求挂起 // 复用同一个刷新Promise } } )实际项目里还做了滑动续期凡是登录态有效期内访问接口就更新Redis里token对应key的过期时间用户连续使用不会突然掉线。这个属于体验细节做完之后用户反馈明显少了用着用着就退了。6.4 匹配结果偶尔看着不合适推荐接口一次返回20条但用户感觉其中有些根本不满足自己的择偶条件。我排查后发现两个原因第一个是前端的筛选条件没传全比如用户只填了年龄偏好后端就只按年龄过滤其他空值不参与校验第二个是活跃推荐逻辑有bug管理员手动推荐了一批用户这些用户绕过了条件过滤直接进了结果集。解决方式很简单前端同步完整偏好表单后端对每个查询条件都做空值判断手动推荐记录也要在详情里打运营推荐标记并且建议跳过严格匹配。6.5 账号安全与敏感词相亲平台的开放私信功能必须加敏感词过滤。最简单的方案是维护一个敏感词表后台可维护消息发送前做一次字符串替换判断。正规一点的做法是引入DFA算法小项目也可以先循环词库过滤。至少要做到涉黄、联系方式相关的词被系统拦截同时保留用户原始内容。另外要把交换微信号这类操作引导到付费解锁功能上这是业务上防止私下流失的常见手段。7. 部署上线与个人经验补充7.1 从开发到上线的关键节点本地开发联调通过后我习惯按这个顺序部署后端打包成jar通过systemd管理前端执行npm run build生成dist目录用nginx托管nginx配置里把/api/反向代理到后端地址同时把前端静态资源和后端文件上传路径交代清楚。nginx的关键配置示例server { listen 80; server_name example.com; root /home/www/dist; location /api/ { proxy_pass http://127.0.0.1:8081/api/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } location /upload/ { alias /data/app/upload/; } }这里有一个很多人忽略的细节WebSocket连接在nginx层需要配置Upgrade头否则聊天功能上线后只有即时通信不生效前端一直等不到消息。我上面这段代码已经写了保存的时候别删掉。7.2 数据备份、监控与运营初期的注意点正式跑数据之后数据库备份不能省。我用的是每天凌晨crontab执行mysqldump保留最近7天。日志收集直接用logback输出到文件按天滚动保留30天。监控这块小项目暂时不上Prometheus但至少要监听jar进程是否存活——挂了自动重启不然凌晨出问题第二天用户全跑光了。运营初期审核压力其实不大但虚假用户这种问题会出现所以举报页一定要第一时间做出来并且给管理员一个证据留痕的功能后台至少要存操作日志。这部分表面上看是业务功能实际影响项目口碑。7.3 最后分享一点实战体会这类前后端分离的相亲网站项目与其堆功能不如把一个闭环做深。我给自己的标准是从注册到聊天、后台审核整条链路没有断点每个环节都有状态提示用户不会卡在我不知道下一步做什么的境地。如果你在准备毕业设计或者面试作品强烈建议把推荐打分算法、WebSocket聊天、RBAC权限模型这三个点讲清楚这比写十个CRUD模块都有价值。实际做下来还有一种体会相亲网站的项目难点不在技术在业务建模。你把择偶条件和用户账号拆清楚把推荐规则、审核流程、互动权限理顺SpringBoot2和Vue3只是顺手的事。做完这个项目你对全栈工程的认识会比做一个普通管理系统高一个层次。