Spring Boot 3 + Vue 3 交友平台全栈项目设计与落地实践

一个很典型的全栈项目后端用 Spring Boot 3前端用 Vue 3做成一个交友平台系统。这类项目在各类毕业设计、个人练手作品里出现频率相当高但大多数写出来都停留在“能跑通”的层面离“能拿得出手”还有不小距离。我聊的不是复刻一个demo而是从一个稍微有点要求的从业者视角把整个系统设计、技术选型、核心模块落地和埋坑经验完整过一遍。这个系统可以解决什么问题适合谁来看如果你是正在做课程设计、毕业设计的学生或者想找一套完整项目练手的前端/后端开发者再或者准备把这套东西改造成商业项目的创业者这篇内容都能给你一个完整的落地方案。文章不会只贴代码而是把每一步“为什么这么干”“还有哪些坑没踩”讲清楚确保你看完不只是会敲键盘而是真的理解这个系统怎么设计、怎么实现、怎么优化。1. 项目定位与技术栈选型的思路1.1 交友平台的核心本质是什么先说一句容易得罪人的大实话交友平台和电商平台在底层架构思路上的相似度远高于差异。都会员体系、有内容流、有推荐逻辑、有站内信、有风控需求。区别只是交易对象从商品换成了人和关系。把这个定位想清楚后面的设计就不会跑偏。比如用户表怎么设计、资料字段怎么扩展都可以参考通用的用户中心方案推荐流不是简单按时间排而是要把“匹配度”这个业务概念落地成可计算的指标聊天不是简单地用 WebSocket 发消息还要考虑离线消息、未读数、敏感词过滤这些真实场景里必须面对的问题。这套系统的功能边界我建议按照 MVP 思路来切用户注册登录、资料完善与编辑、用户推荐与筛选、心动匹配喜欢/不喜欢、匹配成功后聊天。管理端预留用户管理和内容审核。这个范围既是完整闭环又不会在前期拖着不交付。1.2 为什么是 Spring Boot 3 Vue 3为什么不用其他组合Spring Boot 3 是 2022 年底发布的大版本最核心的变化是 Java 17 基线、Jakarta EE 命名空间迁移、Spring Security 6 的引入。很多人在迁移时踩坑恰恰也说明这套技术栈在公司级项目里已经开始普及。换成低版本的 Spring Boot 2安全框架和依赖管理都差一代你写的东西可能一开始就落后于企业的实际招聘要求。前端选 Vue 3 的原因更直观Composition API 和script setup语法让组件逻辑复用变得非常自然再加上 Vite 构建的冷启动速度和热更新体验开发效率确实比 Vue 2 Webpack 时代高出一截。配合 TypeScript项目在规模膨胀时能兜住不少低级错误。也有不少人纠结要不要直接用若依这种脚手架。我的建议是如果是快速交付后台管理系统若依 Vue 3 版本确实省事但这套交友平台的核心业务逻辑——匹配推荐、心动互动、聊天消息——若依并不帮你实现反倒容易被它的代码风格带着走最后写出来的东西不像你自己的。自己从零搭建一个精简版的项目骨架成本并不高还能把所有代码控制在可解释的范围内。2. 系统整体设计从模块拆解到数据库模型2.1 功能模块怎么切才合理整个系统我建议分成四个端用户端前台、用户端聊天服务、管理后台、公共服务模块。用户端前台包含注册登录、个人资料管理、推荐列表滑动卡片、用户详情、心动操作喜欢/不喜欢、匹配列表。聊天服务单独拆出来是因为 WebSocket 连接的生命周期管理、消息推送、断线重连这些逻辑不宜和普通 HTTP 接口混在一个 Controller 里处理否则上线后出问题定位起来非常头疼。管理后台负责用户帐号管理、举报处理、敏感词管理、数据统计。公共服务模块包含文件上传、短信验证码开发期可 Mock、字典维护、系统配置。这种切法最大的好处是开发时可以分模块并行推进测试时可以逐个功能闭环验证部署时也可以按服务拆。如果你做的是毕设单机部署把所有模块放一个应用里也没问题但代码目录结构必须保持这种模块化的形态这是项目能不能持续扩展的关键。2.2 数据库设计核心表结构和字段说明这一块我直接给一套经过实践验证的表设计覆盖主要业务场景。用户主表是地基字段不能太死板。基础字段包含自增主键、手机号、邮箱、密码BCrypt 加密存储、昵称、头像 URL、性别、生日、城市、职业、个人简介、状态字段正常/禁用/封禁。注意身高、收入、教育背景这类交友场景的高频筛选字段不要全都塞进主表单独挂一个用户资料扩展表更合理。扩展表用 user_id 做外键字段包括身高、学历、婚姻状态、兴趣爱好以 JSON 或逗号分隔存储、活跃状态、最后登录时间。标签体系是推荐匹配的重要依据。设计一张 tag 表id、标签名、标签分类、使用次数再用一张 user_tag_rel 关系表id、user_id、tag_id做关联。这样用户可以选择多个标签推荐逻辑统计标签交集时只需要简单 join效率也扛得住。心动记录表字段为主键、用户 ID、被操作用户 ID、操作类型喜欢/不喜欢、操作状态待匹配/已互相喜欢、创建时间。每天操作上限可以限制为 100 次防止刷接口。互相喜欢后在去重约束下生成一条匹配记录匹配表id、用户A、用户B、匹配时间、最近聊天时间、状态负责承载后续聊天会话。消息表是聊天功能的地基包含消息 ID、会话 ID、发送者 ID、接收者 ID、消息类型文本/图片/系统、消息内容、发送时间、已读状态。这个表会持续膨胀上线规模大一点就得按会话 ID 做分表或者引入 MongoDB。但在项目阶段MySQL 按月归档已经足够。举报和敏感词表也建议一开始就建好。举报表结构是主键、举报人 ID、被举报人 ID、举报类型、举报说明、处理状态、处理结果。敏感词表就是一张词库表接口层做文本匹配过滤。2.3 前后端交互协议与统一响应设计前后端分离开发最忌讳接口定义随心情变。建议一开始就约定统一响应格式{ code: 200, message: success, data: {} }状态码 200 表示成功400 表示参数错误401 表示未认证403 表示无权限500 表示服务器异常。业务状态的错误码比如“对方已将你拉黑”“不能对自己操作”这类放在 code 字段里用自定义错误码表示。前端的 axios 拦截器统一判断 code不用每次请求都手写一套异常处理逻辑。接口路径的建议认证相关/api/auth/**用户相关/api/user/**匹配相关/api/match/**聊天相关/api/chat/**。管理后台单独放/api/admin/**每个路径前缀对应不同的访问权限级别配合 Spring Security 配置权限一目了然。3. 核心模块实现认证、资料、推荐、聊天的具体落地3.1 注册登录与 JWT 鉴权链路详解Spring Boot 3 引入了 Spring Security 6这个版本我建议不要只停留在“会配置”的阶段要深入理解认证流程。核心链路是这样的用户注册时密码用BCryptPasswordEncoder加密入库登录时从数据库查出用户比对密码通过后生成 JWT 令牌返回前端。后续请求前端在 Authorization 头携带Bearer token后端通过 JWT 过滤器解析用户信息塞进 SecurityContext。关键实现点有三个。第一个是 JWT 的有效期策略Access Token 建议设置为 2 小时过期后前端用 Refresh Token 调/auth/refresh换取新的 Access Token。如果不做刷新逻辑用户体验就是聊得正起劲突然要重新登录非常掉价。Refresh Token 的有效期可以设为 7 天存在 Redis 里后端收到刷新请求时先校验 Redis 里的 token 是否有效。第二个是登录接口加验证码。图形验证码用 Hutool 的 CaptchaUtil 生成存 Redis 的时候要绑定一个设备指纹前端生成的 UUID有效时间 5 分钟。刷接口的问题用阿里云短信服务做验证码下发开发环境用 9999 这类固定验证码 Mock但代码链路必须完整。不能因为开发期偷懒就不写这层逻辑不然上线前测试会漏掉一大堆问题。第三个是 Spring Security 6 的配置姿势和旧版本完全不同。用新版配置类示例httpSecurity .csrf(AbstractHttpConfigurer::disable) .sessionManagement(session - session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .authorizeHttpRequests(auth - auth .requestMatchers(/api/auth/**, /ws/**).permitAll() .requestMatchers(/api/admin/**).hasRole(ADMIN) .anyRequest().authenticated() ) .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class);注意请求匹配器写法从antMatchers变成了requestMatchers参数也从字符串变成了RequestMatcher对象这是升级后最容易踩的第一个坑。3.2 个人资料与标签体系为匹配算法打地基推荐匹配的质量直接取决于用户资料的结构化程度。很多交友平台把自己的推荐做砸了不是因为算法不够高级而是因为压根没有足够好的特征数据。所以在做资料模块的时候我的建议是让用户在注册时允许跳过信息填写吸引进入后再让用户在浏览推荐卡片的时候顺手补全。前端设计时编辑资料的入口要明显交互要轻量每完成一项资料完善可以弹一个小提示“资料完善度达到 80%曝光度提升 X%”。标签选择的交互要注意不能让用户漫无目的地选 10 个标签那样数据质量很差。正确做法是引导用户选择 3 到 5 个、最多不超过 8 个并且在标签库中优先展示高频热门标签。标签分类可以设计成性格特征温柔、幽默、开朗、兴趣爱好健身、旅行、音乐、生活方式养猫、夜猫子、素食、职业标签程序员、设计师、教师四类。后端存储时标签插到关系表之前要先去重保证同一个标签只能赋值一次。3.3 推荐匹配先用规则打底再考虑算法进阶对于大多数项目阶段来说我强烈不建议一上来就搞协同过滤或者向量召回。数据量不够时算法模型的效果还不如一套设计良好的规则策略。推荐列表的排序可以从这几个维度计算综合评分标签匹配度双方共同标签数每相同一个加 30 分城市匹配同城优先加分 100 分年龄偏好用户在筛选条件里设置的期望年龄区间命中加 50 分资料完善度对方资料完善度高于 80% 的加 20 分活跃度对方 24 小时内有登录行为的加 30 分最终推荐列表按综合分数倒序排列同时把用户已经喜欢或已经划过的人排除掉。实现上先查当前用户的筛选条件再查用户表中符合条件的候选池在内存里算分数排序。候选池数量超过 1 万之后再考虑用 Redis ZSET 做实时排序或者引入 Elasticsearch 做分词和地理位置检索。项目初始阶段用SQL 条件过滤 Java 内存排序完全够用。这里配套一个滑动卡片交互机制。前端每次加载 10 位用户呼出下一批的时机是剩余卡片数小于 3 张时自动预请求。每次滑动操作立即调用匹配接口后端判断对方是否已经喜欢了当前用户如果是返回“匹配成功”标识前端弹窗展示匹配动画生成会话并引导进入聊天如果不是只记录操作结果。为防止匹配延迟这个接口可以异步处理主链路直接返回当前操作结果匹配关系在异步线程里写入前端匹配成功提示以 WebSocket 推送为准。3.4 聊天模块WebSocket 离线消息 敏感词过滤聊天是交友平台留存的核心功能这一块的体验好坏直接决定用户会不会回来。我建议后端用 WebSocket 建立长连接前端用封装后的 Socket 管理器管理连接状态。建立连接时客户端需要把 JWT Token 拼到 URL 的查询参数里服务端通过拦截器完成鉴权并拿到 userId。这样设计的好处是Spring WebSocket 的规范接口里不方便塞 HeaderToken 参数化是最常用的解法。拿到 userId 后把 WebSocket 会话和 userId 的映射关系存到 ConcurrentHashMap 中同时把用户的在线状态同步更新到 Redis并广播一条“好友上线”的事件给匹配过的用户。消息推送链路要处理好三个状态在线直接推送、离线存消息表、对方重新上线后拉取未读数。推送成功后要更新会话的最近一条消息内容同时给前端推送一个“消息已送达”的回执。敏感词过滤这一块建议用 DFA 算法实现而不是简单的批量String.contains判断。DFA 构建词库为树形结构之后匹配效率是 O(n) 级别的十万量级的敏感词库毫秒级完成。过滤的场景覆盖用户昵称、个人简介、聊天文本三处。命中敏感词的消息存储时用*替换敏感词库里的原文不留避免事后吃举报亏。4. 管理后台内容安全与用户运营4.1 审核机制用户举报处理和封禁闭环交友平台最怕的就是出现安全事件之后没有处理链路。管理后台必须包含用户举报列表、举报详情被举报内容、聊天记录截取、资料信息、处理动作忽略、警告、封禁 7 天、永久封禁。封禁操作执行后需要同步清理该用户的在线状态、强制 WebSocket 断连避免已经封禁的用户还能继续发消息。推荐在用户封禁表之外再记录一份封禁操作日志包含操作人员、封禁时长、原因、操作时间。这是为了事后审计也是平台免责的关键依据。4.2 数据统计运营手里得有一份看得懂的报表管理后台统计面板建议显示这些数据注册用户数按天趋势、活跃用户数DAU/MAU、匹配成功数、成功配对率、聊天消息量趋势、日均举报量。这些指标可以通过定时任务在凌晨汇总前一天的数据写入统计表后台查询统计表展示趋势图。前端用 ECharts Vue 3 封装图表组件一眼看清平台状态。统计数字别搞得太复杂先满足核心运营需求后续要精细化再引入 BI 系统。5. 开发环境搭建与部署方案5.1 后端工程结构配置详解创建一个 Spring Boot 3 项目最稳的方式是去 Spring Initializr 生成基础骨架选择 Java 17、Spring Web、Spring Security、Spring Data JPA或 MyBatis、MySQL Driver、Lombok。Sping Boot 3 默认不支持javax命名空间如果你要引入第三方库注意选择兼容jakarta的版本。用 MyBatis 的话请直接引入mybatis-plus-spring-boot3-starter老版 starter 的自动配置在 Spring Boot 3 下会失灵。工程结构按模块分包com.platform ├── config # 跨域、WebSocket、Security 等配置类 ├── controller # 收到 HTTP 请求的入口层 ├── service # 业务逻辑层 ├── mapper # MyBatis 或 JPA 的数据访问层 ├── model # 实体类、DTO、VO ├── common # 统一响应类、异常处理、枚举 └── utils # JWT、敏感词过滤等工具类配置文件中数据源连接用druid连接池Redis 配置序列化器时最好用 Jackson 而不是默认的 JdkSerializationRedisSerializer否则缓存数据在前端对接容易出编码问题。文件上传接口单独配了最大文件大小限制spring: servlet: multipart: max-file-size: 10MB max-request-size: 50MB5.2 前端工程搭建Vite Vue 3 Pinia Element Plus前端骨架用npm create vitelatest初始化模板选vue-ts配合自动导入插件unplugin-auto-import和unplugin-vue-components路由则用vue-router状态管理用Pinia。Vue 3 官方推荐的 Element Plus 组件库在表单、弹窗、表格等场景能极大节省开发时间。安装 scss 依赖只需要两步npm install -D sass然后style langscss scoped直接用就能编译。如果遇到Vite编译sass时报错版本兼容问题大多数情况下是sass版本过新导致legacy-js-api警告可以在 vite 配置里加上css.preprocessorOptions.scss.additionalData或把sass版本锁到1.69.x。跨域问题不要依赖前端代理去解决生产问题。开发环境中 Vite 配置server.proxy把/api代理到后端端口即可但生产环境部署时前后端通常分域部署最稳妥的是在后端 Security 配置中统一加跨域过滤器Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); }注意allowedOriginPatterns(*)和allowedOrigins(*)在携带 Cookie 时有区别前者可以与allowCredentials(true)共存后者不能。5.3 部署上线用 Docker Compose 一把梭单机部署场景下推荐用 Docker Compose 把前端 Nginx、后端服务、MySQL、Redis 四个容器一次性拉起来。核心配置文件贴一下version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: dating_platform ports: - 3306:3306 volumes: - ./mysql-data:/var/lib/mysql redis: image: redis:7.0 ports: - 6379:6379 backend: build: ./backend depends_on: - mysql - redis environment: SPRING_PROFILES_ACTIVE: prod ports: - 8080:8080 frontend: build: ./frontend ports: - 80:80前端 Dockerfile 里用多阶段构建先 node 构建静态资源再拷贝到 nginx 镜像中这样最终镜像的体积会小很多。Nginx 里的反向代理只用配一条location /api/ { proxy_pass http://backend:8080/api/; } location /ws/ { proxy_pass http://backend:8080/ws/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; }6. 开发中踩过的坑与调试技巧6.1 WebSocket 连不上与断线重连问题遇到最多的坑是 Nginx 默认的 60 秒超时导致 WebSocket 连接被切断。配置里必须显式设置proxy_read_timeout和proxy_send_timeout为 3600s同时设置Connection: upgrade的转发头。前端断线重连逻辑要写干净监听onclose事件指数退避重连间隔 1s、2s、4s、8s最大 30 秒重连成功后补偿拉取断线期间的消息。后端也要在会话关闭事件里及时清理内存映射防止会话泄漏导致内存持续增长。6.2 Spring Boot 3 MyBatis 兼容性问题自研项目用 MyBatis 时千万别用mybatis-spring-boot-starter的普通版本否则你会看到Invalid value type for attribute factoryBeanObjectType之类的报错。直接引入dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-spring-boot3-starter/artifactId version3.5.5/version /dependency如果项目里需要分页查询需要额外引入mybatis-plus-jsqlparser依赖3.5.6 版本以上默认分割了分页插件依赖不然PaginationInnerInterceptor会报找不到类的错误。这一点官方文档写得不明显我当时排查了好几个小时。6.3 图片上传后访问 404 的问题Spring Boot 静态资源映射默认不把你上传目录暴露出来。上传文件保存到本地的绝对路径下需要通过一个映射配置把一个 URL 前缀指向本地目录否则前端img src/upload/xxx.jpg会直接 404。这也解释了为什么把上传目录放到资源目录里很多人改不成。最快的解法Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); } }6.4 前后端联调时的日期格式坑接口响应中的日期类型默认是时间戳格式前端处理后能在控制台看到一串数字而不是2024-01-15 14:30:00。统一在 application.yml 里配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8前端获取到之后直接展示省去每个字段手动转换的过程。如果前端也需要传日期字符串给后端配合JsonFormat(pattern yyyy-MM-dd HH:mm:ss)双管齐下确保同一格式反向解析成功。7. 拓展与优化方向这套系统还能怎么升级项目跑通只是起点真正让一个系统有含金量的是后续的扩展思路。推荐策略升级是第一个方向。目前是规则排序积累了足够多的用户行为数据之后可以引入协同过滤用户 A 和用户 B 对一批用户的“喜欢/不喜欢”操作序列相似则 A 喜欢过的用户更有可能被 B 喜欢。这一步用 Python 脚本离线计算给用户打上候选集合后同步到 Redis 即可不用全部推倒重写。即时通讯升级方向是基于 MQ 实现消息异步可靠投递。现在的直接推送方案在用户量几百到几千都没问题但消息量上来后建议引入 RocketMQ 解耦消息先发到 MQ消费端落库并推送削峰填谷消息不丢。这个改造逻辑清晰不会动到上层业务接口。最后想说做这类系统最忌讳的就是停留在“接口能调通”的自我满足上。找一个朋友同时用你的平台互相匹配聊天把所有异常链路走一遍封禁后能不能登录、互相喜欢后消息是否即时到达、长时间在线内存会不会泄漏。这些问题不是写代码时能想到的必须靠真实使用才暴露得出来。项目交付物里能讲清每个模块为什么这么设计、上线前排查过哪些问题比单纯多几个功能点加分得多。