做毕设或者练手全栈项目挑“Spring Boot 基于微信小程序的智能社交网络平台系统”这个方向的人我见过不少。去年下半年我自己也完整搭过一套从后端接口到小程序端页面再到真机预览和部署上线踩了不少坑也沉淀了一套可以直接复用的实现方案。所以这篇东西我不准备写那种“从零开始手把手”的保姆教程而是以项目复盘的形式把关键设计、代码思路、部署细节和踩坑经验一条条讲清楚。正在做类似项目、或者打算用这套技术栈做毕设的朋友可以拿着直接参考。先说清楚这套系统能做什么用户通过微信授权登录维护个人资料和兴趣标签发布图文动态浏览基于兴趣匹配的“智能推荐流”和按热度排序的“热门动态”可以关注其他用户、点赞、评论后台还能用对象存储统一管理图片资源。后端用的是 Spring Boot MySQL Redis MinIO前端是原生微信小程序。功能不贪多但主链路完整、可演示、可上线毕设演示或者接外包预演都够用。1. 项目全景这个“智能社交网络”到底做什么1.1 核心需求拆解用户、内容、互动三条线做社交平台最容易犯的毛病是一上来就想做全私信、群组、直播、短视频全往里塞。实际做项目的时候我建议先把需求收敛成三条主线用户、内容、互动。用户线解决“我是谁”。微信小程序天然适合做社交平台的入口因为 wx.login 可以直接拿到身份标识不需要用户注册账号和密码。用户进来之后第一步是微信授权登录第二步是完善资料最关键的是选择兴趣标签。这个标签不是 UI 上的装饰它是后面所有“智能推荐”的数据基础直接影响推荐算法能不能跑起来。内容线解决“看什么”。用户发布动态支持文字加多张图片这是社交产品最核心的内容载体。内容相关要设计好状态字段比如可见范围、审核状态、删除状态。在毕设阶段可以不做敏感词审核但建议预留一个 status 字段方便以后扩展。互动线解决“怎么连接”。关注、点赞、评论是社交网络的基础三件套。这套系统里我做了关注关系表点赞和评论都单独建表。注意点赞有两个状态已赞和未赞做数据库设计的时候要保留唯一索引防止同一用户对同一动态点两次赞。把这三条线理清楚之后整个项目的接口边界就非常明确了登录一个接口用户资料维护一个动态发布一个动态列表和推荐各一个关注一个点赞一个评论一个。前后端联调的时候按这个清单走效率高得多。1.2 “智能”体现在哪里标签匹配与热度排序这个项目的名字里有“智能”两个字很多人就以为要上深度学习、协同过滤。真做的时候你会发现在数据量非常有限的情况下花哨的算法根本跑不起来反而是一个朴素的“标签匹配 热度排序”方案最可靠也好解释。我的实现方式是这样的用户在完善资料时勾选兴趣标签比如“编程、篮球、摄影”。每条动态发布时后端调用 HanLP 对正文做分词和关键词提取得到这条动态的主题词集合。推荐动态时计算“当前用户标签集合”和“候选动态主题词集合”的余弦相似度得到一个内容匹配分。同时我维护一个热度分用点赞数、评论数、浏览量和发布时间做加权热度分 0.4 × 点赞数 0.3 × 评论数 0.2 × 浏览量 时间衰减。最终推荐流的排序分数 0.7 × 内容匹配分 0.3 × 热度分。这套公式虽然简单但在毕设答辩或者项目演示的时候很好讲为什么推荐这么“准”因为有用户标签和内容标签在起作用。为什么不会推荐太旧的内容因为有时间衰减。整个推荐逻辑用一个方法就能实现不需要引入额外的大数据组件跑起来也没压力。1.3 技术选型为什么是 Spring Boot 微信小程序这个组合几乎是当前国内全栈入门和毕设项目的标配核心原因是“两端都有大量成熟实践”。服务端选 Spring Boot因为它把 Spring 复杂的配置简化成了“依赖 注解 配置文件”三件套项目搭建速度很快。尤其是 2.7.x 版本稳定、资料多、和三方库兼容性好遇到任何问题几乎都能搜到解决方案。我实测过 Spring Boot 3.x功能上新版当然更好但它默认基于 JDK 17部分三方库版本跟不上在项目周期紧的情况下没必要给自己增加额外风险。小程序端用原生微信小程序而不是 uni-app原因也很直接这个项目的核心页面就那几个原生语法完全够用而且调试工具成熟社区资料多。如果之后想扩展到 App再用 uni-app 跨端也不迟但前期不建议为了“将来可能的需要”牺牲开发效率。2. 服务端设计Spring Boot 的骨架搭建与实际配置2.1 工程结构、版本与基础依赖我采用的是常见的分层结构分包逻辑是controller 只做参数接收和结果返回service 写业务逻辑mapper 操作数据库entity 和 DTO/VO 分开。这样的好处是职责清晰答辩的时候讲代码结构也很好讲评委会觉得你确实按工程规范在做而不是所有代码堆在 Controller 里。pom.xml 里的核心依赖就这些spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-j、lombok、jjwtJWT 生成和解析、minio对象存储客户端、hanlp分词。版本上我用了 Spring Boot 2.7.18这是 2.x 系列的最后一个维护版本稳定且兼容性最好。需要特别注意一个坑如果你引入 HanLP 的完整版它默认会下载或加载较大的模型数据在服务器内存不足的情况下很容易 OOM。我的做法是只用 HanLP 的标准分词功能并配置了一个精简词典路径不加载完整模型保证整个服务在 2G 内存的服务器上能跑起来。2.2 微信登录鉴权code2session 与自定义 token 的完整链路微信小程序登录的核心逻辑不复杂但很多人第一次做都会在“code 换 openid”这一步卡住。完整流程是这样的前端调用 wx.login 拿到临时 code这个 code 的有效期短且只能用一次后端拿到 code 后调用微信接口jscode2session用 appid 和 appsecret 换取 openid 和 session_key然后用 openid 去查用户表查不到就新建用户查到了就更新最后登录时间最后用自己的 JWT 生成 token 返回给前端前端把 token 存进 storage后续所有请求都在 header 里带上。这里有个安全细节必须强调code2session 返回的 session_key 绝对不能下发到前端。session_key 是微信会话密钥它有自己的用途比如解密手机号等敏感数据。很多新手直接把 session_key 塞到登录接口返回里这是非常危险的。正确做法是服务端拿到 openid 之后session_key 只保存在服务端内存或缓存里需要解密再取用不该进响应体。JWT 的生成也很简单。我用的签名密钥是一个随机字符串至少 32 位不要写在代码里明文而是放在 application.yml 配置文件中。token 有效期我设为 7 天前端在收到 401 时自动重新调用 wx.login 换取新 token不需要用户手动重新授权。这套机制跑起来很顺也不容易出现掉登录的问题。2.3 数据库模型用户、动态、关注、点赞、评论表结构设计决定了后期开发的流畅程度我在这个项目里一共建了就张核心表每张表都遵循一个原则不做冗余复杂的关联查询只保证主链路查询高效。user 表id、openid唯一索引、nickname、avatar、gender、bio、tagsJSON 字符串存逗号分隔或 JSON 数组、create_time。openid 是用户身份的唯一凭证必须加唯一索引。feed 表id、user_id、content、imagesJSON 字符串数组、view_count、like_count、comment_count、hot_score、create_time。这些 count 字段是冗余的用来做列表展示不需要每次实时 count 评论表。follow 表id、user_id、target_user_id、create_timeuser_id 和 target_user_id 加联合唯一索引。like_record 表id、user_id、feed_id、create_timeuser_id 和 feed_id 加联合唯一索引。这里没有任何记录因为只要删除就行。comment 表id、feed_id、user_id、content、create_time。我当时还在 feed 表加入了一个 score 字段专门存热度分。这个分数用定时任务每十分钟刷一次就行不用实时计算避免推荐接口每次请求都要跑一遍权重计算。定时任务用 Spring 自带的Scheduled就可以加上EnableScheduling开启。2.4 文件资源管理为什么用 MinIO动态需要发图片头像需要上传这些文件总不能直接塞数据库。最直接的方案是把图片存到服务器本地磁盘然后前端通过静态地址访问看起来很简单对吧但实际有个大问题如果你后面把服务部署成多个实例或者迁移服务器本地磁盘的文件就丢了而且磁盘扩容不方便。所以我用了 MinIO 做对象存储。MinIO 是一个开源的轻量级对象存储服务兼容亚马逊 S3 协议一条 Docker 命令就能启动特别适合中小项目和毕设场景。你只需要在服务器上跑一个 MinIO 实例给它配好 accessKey 和 secretKey然后在 Spring Boot 里引入minio的 Java SDK就能完成文件上传、下载、删除。我在项目里的文件上传流程是前端调用后端上传接口把图片以 multipart 形式提交后端收到文件后用 UUID 生成唯一文件名写入指定 bucket写完后返回一个可访问的 URL前端再把 URL 存到 feed 表的 images 字段。这里面有两个细节要注意一是 bucket 策略要设置为公开读否则前端图片加载不出来二是 accessKey 和 secretKey 要放到配置文件的application-prod.yml里不要写死在代码中。3. 小程序端实现不是套模板而是把体验做顺3.1 请求封装与登录态管理小程序端最忌讳每个页面直接调用 wx.request然后重复写一堆错误处理逻辑。那样做前期写起来爽后期改一个接口地址、加一个公共 header 的时候你就得把所有页面翻一遍。所以第一步一定是封装请求工具。我的封装思路很简单写一个request.js工具模块内部用 Promise 包装 wx.request自动读取本地 storage 里的 token 放到 Authorization 头统一处理后端返回的 401 和业务错误。核心代码如下const request (path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, success(res) { if (res.statusCode 200) { resolve(res.data) } else if (res.statusCode 401) { // token 过期重新登录后重放请求 } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(res) } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) }这里的 401 处理是很多项目最容易漏的地方。token 过期后如果前端不做任何处理用户在用着用着就会突然发现所有请求都失败体验极差。我在封装里加了一个“正在刷新 token”的判断如果当前没有在刷新就调用一次登录接口拿新 token同时用一个新的 Promise 等待刷新完成后重发之前失败的请求这样用户完全无感知。3.2 列表加载更多触底分页的标准做法社交产品最核心的页面就是信息流列表如果分页做不好列表会出现重复数据、加载抖动、卡死等一堆问题。小程序里实现加载更多依赖onReachBottom生命周期但只是触发还不够背后的分页状态要管理好。我保存三个关键状态page表示当前页码hasMore表示是否还有更多数据loading表示当前是否正在请求。每次触底时都会判断 hasMore 和 loading 这两个条件防止同一个请求被连续触发多次。加载成功后把新数据concat到旧数据后面并更新 page 和 hasMore。后端接口则使用 MyBatis-Plus 的分页插件入参是page和pageSize返回数据里除了列表外还带一个hasMore字段让前端不用再自己算总数判断。这个设计比返回total更直观前端写起来更省心。onReachBottom() { if (this.data.hasMore !this.data.loading) { this.setData({ page: this.data.page 1 }) this.loadFeeds() } }对了这里有个菜鸟容易踩的坑onReachBottom在 iOS 上触发频率比较高如果不在loadFeeds里把loading置为 true那么在请求还没回来的时候用户快速滑动就会产生大量重复请求图片加载顺序还会乱。把 loading 状态作为请求锁是这类列表页必须做的事。3.3 顶部导航栏高度适配与自定义导航如果不做自定义导航栏页面最上方显示的是微信原生导航标题、背景颜色、返回按钮都是系统默认样式很多项目为了展示效果会做成自定义导航。一旦自定义第一个难点就是计算导航栏高度。微信小程序本身不提供直接获取导航栏高度的 API但可以组合计算先用wx.getMenuButtonBoundingClientRect()拿到右上角胶囊按钮的上下位置和高度再用wx.getSystemInfoSync()拿到状态栏高度。导航栏高度等于“胶囊按钮的 top 减去状态栏高度后乘以 2再加上胶囊按钮高度”。这个公式看起来绕但其实就是算出了胶囊按钮上下两边留白加上内容高度。const menuButton wx.getMenuButtonBoundingClientRect() const statusBarHeight wx.getSystemInfoSync().statusBarHeight const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height这个值拿到以后所有自定义导航页面都用它来撑起顶部占位保证页面内容不会被状态栏遮住。如果不用自定义导航这部分可以跳过但如果你在做一个外观比较精致的社区类小程序自定义导航基本是必须的。3.4 智能模块落地推荐流的实现策略推荐流是这套系统名字里“智能”的最终体现我在项目里的落地方式是做一个/feed/recommend接口。后端接收当前用户的标签集合然后从候选动态池里取一批最新或评分较高的动态对每条动态做分词提取主题词再计算与用户标签的余弦相似度。最后按相似度和热度分做综合排序。小程序的 UI 端推荐流和普通动态列表在数据展示上几乎一样不同的是排序逻辑在后端。所以前端只要在进入首页时调用推荐接口然后复用那个加载更多的分页逻辑即可。有一个值得注意的地方候选集不能无限大否则每次请求去遍历所有动态做分词数据库和 CPU 都会吃不消。我的做法是先用 SQL 按时间或热度圈出一个候选范围限定每批最多几百条再在内存里做匹配计算。这样既保证了效果也保证了性能。对一个小型社交平台来说这个量级已经足够。4. 从本地到上线部署、调试与联调中的真实问题4.1 本地联调三步走真机预览、局域网 IP、域名白名单很多新人在本地把后端跑起来之后发现小程序模拟器里能请求数据但手机上一片空白就在那怀疑代码有问题。其实大概率不是代码问题而是环境问题。第一步模拟器开发时需要在微信开发者工具里勾选“不校验合法域名”。不勾选的话模拟器会拦截所有 HTTP 请求报“不在以下 request 合法域名列表中”。第二步真机预览时手机和小程序模拟器访问的 IP 必须一致。如果你的电脑是 192.168.1.100后端在 8080 端口小程序里的 BASE_URL 就要写成http://192.168.1.100:8080而不是http://localhost:8080。第三步电脑防火墙要放行 8080 端口否则手机根本连不上。这三个问题排查完真机联调基本就能通了。如果还有问题下一步就是抓包看请求到底有没有发出去以及后端有没有正常返回。4.2 服务部署从 Jar 包到 Docker本地联调通过之后下一步是把后端服务部署到服务器。我推荐直接上 Docker因为服务器环境干净不用手动装 JDK 和 MySQL用 docker-compose 一条命令就能把后端、数据库、对象存储全拉起来。后端服务我写了一个简单的 DockerfileFROM openjdk:8-jre-alpine WORKDIR /app COPY target/social-platform.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar, --spring.profiles.activeprod]注意这里我指定了--spring.profiles.activeprod因为生产环境和开发环境的数据库地址、MinIO 地址都不一样。生产环境配置通过环境变量注入到容器里比如数据库密码、JWT 密钥这些敏感信息不要在镜像里写死。部署完成后还需要把后端域名配上 HTTPS并且在小程序后台把 request 合法域名、uploadFile 合法域名配好。微信小程序正式版要求所有请求域名必须为 HTTPS且需要在后台配置白名单这一步不做用户一打开小程序就全是请求失败。4.3 接口调试用抓包工具排查小程序请求联调和上线过程中最实用的调试手段就是抓包。用 Charles 配好代理和 SSL 证书之后你能在电脑上看到小程序发出去的每一个请求、请求头、请求体和返回结果。对于排查“为什么真机上接口报错但模拟器正常”这类问题抓包是最高效的手段。实际使用中我一般这样操作手机 Wi-Fi 代理指向电脑 IP 和端口电脑上 Charles 安装证书并配置好 SSL Proxying。这时真机小程序的所有请求都会在 Charles 里显示出来你可以看到 BASE_URL 是否走对、token 是否带上了、后端返回的具体错误是什么。有一次我排查一个问题前端一直提示“请求失败”但代码上看不出原因抓包才发现是 token 在某个版本更新后没重新登录导致所有接口 401改好登录逻辑就解决了。值得提醒的是抓包工具只用于自己项目的开发调试不要用它去抓取和分析他人应用的数据也不要试图绕过任何安全机制。这是基本的职业边界。4.4 小程序审核前要过的那些坎项目做完要上线还得过微信官方审核。审核最容易踩的坑有这么几个第一是类目选择。社交类目在小程序后台是有门槛的如果你要做开放社区、信息发布可能需要额外的资质文件。对于毕设项目你可以选择先以“工具”或“个人”类目提交功能描述里不要写“开放社区”这类字眼而是写“基于兴趣的内容浏览平台”降低审核难度。第二是隐私政策。现在的小程序必须在用户首次启动时展示隐私政策明确告知收集了哪些信息、用于什么目的。我就在项目里加了一个隐私弹窗不点同意不让进入首页。第三是用户授权变化。现在不能通过wx.getUserInfo直接弹窗获取用户头像和昵称了必须在界面上放一个 button让用户主动点击授权后才能拿到。这个改动如果不做审核会直接退回。5. 踩坑实录一组实战问题与排查速查表5.1 常见问题速查下面是整个项目开发过程中我遇到过的典型问题整理成一张速查表可以直接对照排查现象可能原因处理思路wx.login 获取的 code 报 invalid codecode 只能用一次可能被重复提交登录逻辑加防重入后端打日志查看调用次数真机预览连不上本地后端手机和电脑不在同一网段或防火墙未放行固定电脑局域网 IP放行 8080检查 BASE_URL上传到 MinIO 的图片 URL 打不开bucket 策略为私有读设置 bucket 为 public read或后端返回预签名 URL列表页反复加载、图片乱onReachBottom 频繁触发没有 loading 锁在请求前判断 loading返回后再置为 false小程序请求报“不在合法域名列表”开发阶段未勾选“不校验合法域名”开发工具里勾选正式版在后台配置 https 域名用户头像昵称获取不到微信调整了授权方式用 button 的 open-type 触发授权不用 wx.getUserInfoSpring Boot 启动报错三方库不兼容用 Spring Boot 3.x 但依赖没升级换 2.7.x或者升级所有依赖适配 Boot 3服务器上服务经常内存不足部署资源太紧或加载了完整 HanLP 模型用精简词典服务内存别低于 2Gtoken 过期后接口一直失败前端没有重新登录逻辑请求封装里加 401 自动刷新 token5.2 可以继续深挖的三个方向这套系统做完之后想再往上扩展的话我个人觉得有三个方向最值得研究。第一个方向是把私信功能做成完整的会话模块用 WebSocket 做实时消息推送这样项目从“单向浏览”变成了“实时社交”。第二个方向是在点赞、评论、关注这些高频率操作上引入 Redis 缓存。先写缓存、异步刷库再配合消息队列做削峰这样系统在高并发场景下不会被打垮。第三个方向是升级推荐算法等有了一定用户行为数据之后可以做“基于用户的协同过滤”或者“基于物品的协同过滤”而不是一直用标签匹配。这三个方向无论是写进论文还是当作下阶段开发计划都很有说服力而且每个方向都能单独拆成一个小的技术专题来讲。整个项目做下来我最大的体会是不要小看这套看起来“普通”的技术栈组合。Spring Boot 负责把后端业务逻辑理顺微信小程序负责把前端交互做得自然顺滑两者之间的联调、部署、审核这一整条链路才是真正让人长本事的地方。如果你正在做类似的项目建议先把登录鉴权和请求封装这两块彻底吃透因为几乎所有功能页面都离不开它们。踩过几次坑、改过几版代码之后你对全栈开发的认识一定会比看教程深得多。