微信小程序菜谱平台：Spring Boot与MySQL源码全拆解

1. 拆解标题这个菜谱小程序到底做了什么1.1 从标题反推核心功能需求先说结论这份源码的核心是一个基于微信小程序的在线菜谱学习与分享平台。标题里“学习”和“分享”四个字基本就把功能切成两大块了。“学习”对应的是内容消费侧用户打开小程序可以浏览菜谱、按分类找菜、看详情页里的食材清单和步骤、跟着教程做菜。这要求平台必须有完整的菜谱内容结构——一道菜要拆成主图、简介、食材列表含用量、步骤每步配图或文字、烹饪时长、难度、口味标签等。“分享”对应的是内容生产侧用户自己会做菜可以把菜谱传上来配上图片、写清楚步骤发布到平台。这就意味着系统里要有一整套发布流程、图片上传机制、内容审核机制还要有用户体系来区分“谁发的、谁看的、谁收藏的”。再往深了想既然有发布和浏览一定少不了一堆社区产品的标配首页推荐流、分类筛选、搜索、点赞、收藏、评论。这些功能加起来就是一个完整的轻量级内容社区。所以这份源码其实不是简单的一个静态菜谱展示而是一个“UGC用户生产内容 内容消费”双端闭环的小程序项目。这个定位正好就是小程序生态里最典型、也最适合练手的项目类型。我在学校带过不少做毕设的学弟菜谱类、旅游类、二手交易类、社区团购类本质上都是这套结构换了个壳用户登录、内容列表、详情页、发布入口、我的页面。学会一套其他都能套。1.2 菜谱平台的三大设计难点很多人以为这类项目就是“增删改查套模板”真正上手写才发现没那么简单尤其菜谱这种内容形态有三个特殊坑第一个是图片流比重极高。一道菜少说三五张图首页列表要出缩略图、详情页要大图、发布要传多图。图片怎么压缩、怎么缓存、怎么兼容不同屏幕尺寸直接决定小程序跑得顺不顺。我在自己项目里就吃过亏不限制上传图大小结果用户上传 5MB 的照片列表页直接卡顿掉帧。第二个是数据结构的差异化。菜谱不像新闻只有一个标题加正文它有食材数组、步骤数组、标签数组是一坨结构化的嵌套数据。后端怎么设计表、前端怎么渲染这种混合结构比普通列表要复杂不少。搞不清楚的话发布功能存进去的数据详情页取出来对不上非常折磨。第三个是内容审核和社区治理。有 UGC 就有水贴、广告、违规内容菜谱平台也一样。图片审核调不调第三方接口、文本敏感词怎么过滤、用户举报怎么处理这些在课程设计里可以不深入但放到正式上线就是必然要面对的事。源码里如果做到了基础审核含金量就上了一个档次。这三个难点决定了你在看这份源码、或者照着它自己动手做的时候重点该盯着哪些文件、哪些表、哪些接口而不是对着密密麻麻的代码瞎翻。2. 技术选型为什么是微信小程序加这套后端组合2.1 微信小程序 vs App vs H5选型背后的考量先聊一个挺多新手纠结的问题既然是菜谱平台为什么非要用微信小程序而不是做个 App 或者 H5 网页从产品角度说微信小程序的获客成本是三者里最低的。分享一个菜谱链接到群里朋友点开直接就能用不用下载 App、不用注册账号微信授权一键登录。菜谱这种东西天然带有社交传播属性——看到一道好菜顺手转发给“相亲相爱一家人”群这个场景 App 根本做不到小程序是唯一解。从开发角度说小程序生态已经非常成熟。微信开发者工具自带模拟器、真机调试、预览二维码一套代码跑 iOS 和 Android 微信不用分别适配两套原生技术栈。对个人开发者或者学生党来说这是性价比最高的选择一个人加一台电脑就能撑起一个项目。至于 H5虽然开发门槛最低但有个致命短板没有微信的流量入口。用户不会收藏你一个网页链接但会愿意留下一个小程序在“最近使用”里。加上小程序有订阅消息、支付、分享卡片等等一系列微信原生能力做菜谱这种内容互动型产品小程序就是比 H5 多一层社交基建。所以这份源码选了小程序不只是技术选择更是一个符合产品逻辑的商业判断。你以后自己设计项目的时候也应该先想清楚我的产品靠什么获客、用户凭什么留下来、什么端最匹配用户场景。想清楚了再动手比闷头写代码重要得多。2.2 后端技术栈Spring Boot MySQL 的真实分工从标题和源码附带的说明来看这套项目走的是主流教学路线前端微信小程序后端 Spring BootJava数据库 MySQL。先解释一下这三者的分工新手别被一堆名词唬住。前端小程序负责三件事画界面WXML 写结构、WXSS 写样式、处理交互JS 写逻辑、和后端通信用微信提供的wx.request发 HTTP 请求。也就是说用户在手机上看到的一切都是前端干的活。后端 Spring Boot 负责的是“服务端逻辑”接收前端发来的请求处理业务规则比如判断用户登录态、校验菜谱数据是否完整、查数据库、组织数据再返回给前端。它是中间层既管“接口”URL又管“数据组装”。数据库 MySQL 负责的就是单纯地存数据用户表、菜谱表、分类表、评论表、收藏关联表。Spring Boot 通过 MyBatis 或者 JPA 这类持久层框架把 Java 对象和数据库表映射起来实现“查表——转对象——给前端”。这套组合的教学意义非常大。Java 后端是目前国内企业用的最广的解决方案大学生校招简历上写“熟悉 Spring Boot MySQL”基本是标配小程序前端又有微信官方文档兜底出了问题去哪查都方便。给想要拿这份源码学习的读者一个建议第一遍跑通以后不要急着改功能先看懂后端 Controller控制层 和 Service服务层 的划分。Controller 负责接收请求Service 负责业务逻辑很多人写项目把代码全堆在 Controller 里那后面项目一大人就疯了。看源码学习最重要的就是看人家的代码怎么分层、怎么组织。2.3 云开发与自建服务器的取舍这里多说一个题外话现在微信小程序还有一个非常省事的后端方案——云开发微信云托管/云函数。用云开发的话你不需要自己买服务器、不需要自己配域名和 HTTPS 证书直接在微信开发者工具里开通云能力数据库、存储、云函数一站式搞定。那为什么很多项目包括这份还是用“自建后端 云服务器”的经典模式我觉得核心原因是两个第一教学兼容性。大学的服务器课程、Java 课程、数据库课程教的全是传统架构。用云开发相当于把后端那套全黑盒化了上课学的技术没处用毕业答辩的时候也不好讲。传统模式至少能把分层架构、数据库设计、接口文档全展示出来老师看了觉得工作量扎实。第二岗位匹配度。招 Java 后端开发的公司看的是你操作 Spring Boot、写 SQL、调优接口的能力。你用云函数做毕设简历上面试官根本不知道从哪儿问起。传统模式写一遍面试被问到“你的项目怎么处理并发”“你的数据库索引怎么设计”才有得聊。所以我个人的态度很明确如果只是自己做个工具玩玩用云开发一小时搞定如果是学习、毕设、求职作品集老老实实走传统前后端分离架构。这份源码选后者是对的。3. 核心模块的代码级拆解与实操要点3.1 登录鉴权wx.login 到 token 的完整链路小程序登录和传统网页登录不一样最大的区别在于小程序没有“账号密码”这个概念它靠微信的身份体系来识别用户。整个链路是这样的第一步前端调用wx.login()拿到一个临时凭证code。这个 code 有效期很短几分钟而且只能用一次它本身不是用户身份只是一张“兑换券”。第二步前端把这个 code 通过wx.request发给后端的登录接口比如/api/user/login。第三步后端拿这个 code向微信服务器发请求接口地址是https://api.weixin.qq.com/sns/jscode2session同时带上你的小程序 AppID 和 AppSecret微信那边就会返回两个关键信息openid用户在你这小程序里的唯一 ID和session_key会话密钥。第四步后端拿着 openid 去数据库的 user 表里查查得到说明是老用户查不到说明是新用户得先在库里给人家建档。第五步后端生成一个自定义登录态——最常用的就是 JWTJSON Web Token把用户 ID、过期时间等打包加密成一个 token 字符串返回给前端。前端拿到后存到wx.setStorageSync里后续所有需要登录的请求都在 header 里带上这个 token。这个流程看源码的时候一定盯准了有的菜鸟写法会在前端就把 openid 存起来发给后端那等于把自己的通行证交到路边摊安全问题就大了。规范的做法就是“前端给 code → 后端换 openid → 后端发 token”openid 永远不出后端。源码如果也是这么设计的那它的登录模块可以直接当范本抄。实际调试中常踩的一个坑是后端拿 code 去微信换 openid 的时候需要正确配置 AppID 和 AppSecret。用开发者工具测试时可以勾选“不校验合法域名”但真机预览就会报request:fail那是微信域名校验的原因不是代码逻辑出了问题我在下面第 4 部分还会专门讲。3.2 菜谱列表分页加载与数据流设计菜谱列表是内容的门面首页直接决定用户留不留下来。这里源码大概率做了这几层内容首页顶部的分类导航这个最简单就是几排可切换的标签家常菜、川菜、烘焙、汤羹之类的点击某个分类列表就替换成对应的菜谱数据。列表数据用“分页加载”的机制对应小程序里的两个生命周期函数onPullDownRefresh下拉刷新和onReachBottom触底加载更多。前端每次请求后端接口时带上page页码和pageSize每页数量后端返回一页数据以及一个total总条数前端判断当前已加载条数 total就继续允许加载更多否则提示“没有更多了”。这段逻辑看源码时注意一个细节加载状态管理。很多新手写翻页时漏了isLoading这个标志位用户疯狂下滑的时候一个请求还没返回又一个请求发出去了数据就乱套了。规范的写法是请求发出时置isLoading true返回后置false只有当isLoading false时才能发起下一次请求。这个标志位就像洗手间的门锁进去锁上出来才开门。另外一个值得学的是列表数据流设计。前端往往不是直接把接口返回的数据塞进数组而是用一个当前页面的data字段专门管理列表状态。我见过很多半吊子源码一个页面七八个数组互相拷贝改一个忘了另一个bug 查一晚。好的做法是列表数据只有一个来源其他都是派生视图。首页列表的单条菜谱卡片一般包含封面缩略图、菜名、一句话描述、浏览/收藏数。前端渲染用的是wx:for配合wx:key提升 diff 性能。图片做列表展示时建议统一用后端返回的压缩图 URL别拿原图直接怼列表这里省出来的流量和时间用户是能感觉到卡不卡的。3.3 发布菜谱图片上传的前后端配合发布是 UGC 项目里最麻烦的一个模块比列表逻辑复杂多了。一个完整的发布页面至少有这些元素菜名输入框、分类选择器、食材输入可动态增删多行、步骤输入每一步可传图、封面图选择、难度/时长选择、提交按钮。这个环节里最考验工程能力的是图片上传。小程序端上传图片的流程是用户通过wx.chooseMedia选择或拍摄图片拿到本地临时路径比如wxfile://tmp_xxx.jpg然后前端把这个临时文件通过wx.uploadFile发送到后端的图片上传接口。这里注意wx.uploadFile和wx.request不一样它是 multipart/form-data 格式而且不支持自定义 header 里的 content-type所以在后端接收时要用MultipartFile来接收文件参数千万别用 JSON。后端收到图片后一般会做三件事先校验文件类型和大小白名单校验只允许 jpg/png/webp大小限制比如 5MB然后生成一个唯一的文件名用 UUID 或者时间戳加随机数避免文件名冲突保存到服务器的上传目录或者 OSS对象存储最后把能访问到这张图片的 URL 拼出来存到数据库里。这里还要看源码如何组织“菜谱”和“食材/步骤”这两层嵌套数据。菜谱主表菜名、分类、封面、作者等是一条记录食材和步骤是子表一条菜谱对应多条食材、多个步骤。新增菜谱时前端把食材列表、步骤列表作为数组和后端约定好格式JSON 字符串或者直接 List 对象后端先插入主表拿到菜谱 ID再循环插入子表。必须开事务保证主表和子表要么都成功要么都回滚不然后台数据就千人千面了。我在这里踩过一次大坑发布接口没做事务主表插入成功了子表插到一半网络抖一下断了结果就是详情页能打开但里面没内容。后来我测试所有写接口强制要求在事务注解里执行并且在业务层捕获异常时手动回滚再没出过这种脏数据事故。3.4 搜索分类与互动功能的实现细节搜索这个功能看起来简单就是一个搜索框加一个列表但背后也有设计讲究。最常见的实现是后端 SQL 的模糊查询类似SELECT * FROM recipe WHERE name LIKE %${keyword}%。这个写法问题不大但要提醒两点一是防止 SQL 注入用 MyBatis 的话正确姿势是${}换成#{}拼参数或者用CONCAT(%, #{keyword}, %)二是当菜谱量上来之后LIKE %xx%走不了索引全表扫描会越来越慢届时要引入搜索引擎如 Elasticsearch或者 MySQL 全文索引。分类筛选相对简单一个分类字段的等值查询就够了。但要注意“分类”的前端表现很多小程序采用的是“顶部横向 tab 左侧竖向分类”的组合逻辑都是同一个——请求时带上分类 ID。点赞、收藏、评论这三个互动模块核心是搞清楚它们和用户的关联关系。以收藏为例数据库里要有一张 user_favorite 表用户ID、菜谱ID、创建时间前端收藏按钮显示的状态就是“当前用户ID 是否在这张表里有一条对应记录”。切状态时前端调收藏/取消收藏接口接口通过增删表记录来实现。这里有个经验为了性能前端点收藏时不要等服务端返回再改 UI可以先改 UI乐观更新失败了再回滚体验好很多。评论功能要注意的是层级和排序。简单场景下只做一层评论就够了用户在这道菜下面盖楼留言复杂一点的还要做回复某人。排序一般是按时间倒序最新的在前。发布评论后要让列表马上看到新内容两种常见做法一是重新拉取简单粗暴二是本地往数组里 push 一条记得在生成评论对象时补齐昵称头像等展示字段。4. 从源码到跑通本地运行与真机调试全流程4.1 项目导入与依赖准备拿到源码第一个感觉基本都是“这么多文件从哪下手”我按顺序给你捋一遍照着操作基本不会卡壳。后端部分打开 IDEA或者 Eclipse选择导入 Maven 项目等待依赖下载完成这一步慢是正常的首次要拉几百 MB 的 jar 包网络不好建议开国内镜像源。然后改配置文件重点看 application.yml里面是 MySQL 数据库的连接信息jdbc:mysql://localhost:3306/菜谱平台数据库名、用户名、密码。改完以后在 Navicat 或者其他数据库工具里执行源码附带的 SQL 脚本一般是.sql文件把库表结构和初始数据建出来。启动后端前建议先确认三件事一是 MySQL 服务有没有起二是在application.yml里配置的数据库名和密码是否和本地一致三是项目用到的端口比如 8080有没有被占用。有一个配置配错了启动直接就报错报错日志里都写了原因别怕读英文报错一行一行看多数问题都是白字明说的。前端部分打开微信开发者工具选择“导入项目”目录指向源码里的前端文件夹。导入时会让你填 AppID这里有两个选择你有小程序账号就填自己的 AppID没有可以先点“测试号”。如果你只是本地预览测试号完全够用但真机预览和调用微信登录接口就要真实 AppID 了这个后面会讲。首次打开前端项目大概率会报错别慌。最常见的两个一是app.js里请求的后端地址写的还是服务器 IP 或者线上的域名跟本地对不上改成本机局域网 IP比如http://192.168.x.x:8080二是project.config.json里的appid和你的不一致直接替换成自己的就行。4.2 接口联调与权限配置前后端都跑起来以后还得让它们“对上话”。这里面最常被卡住的一道门槛是请求合法域名。微信小程序的规则是wx.request、wx.uploadFile请求的 URL必须是 HTTPS 并且在小程序后台配置了“request 合法域名”否则线上突然就打不开了。但在开发环境下微信开发者工具给了个后门右上角“详情”面板 → “本地设置” → 勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。开发阶段勾上它本地用 http://localhost 或者 http://192.168.x.x 都能正常访问后端。真机预览的时候就没有这个后门了。想拿自己手机扫码测试本地服务办法是有的把电脑和后端保持同一局域网手机微信扫预览码但真机访问不了localhost必须用电脑的局域网 IP。后端启动时如果用默认 localhost 监听外面访问不到启动命令带上--server.address0.0.0.0或者直接在配置文件里配address: 0.0.0.0。这里的实际操作经验是iOS 和 Android 对 IP 的抑制策略不一样真机预览接口不通很大概率是系统防火墙拦了端口。解决方案是临时给防火墙加一条入站规则允许对应端口的 TCP 连接或者直接关防火墙试一次通了再去找精确规则。如果你后端配了 JWT 鉴权还有一个细节点本地调试时用wx.setStorageSync(token, xxx)手动塞一个假 token 是行不通的后端校验失败直接 401。正确做法是走完整登录流程让后端把真 token 吐出来存进本地缓存里这样后续每个接口才能带对身份。调试登录模块的时候开发者工具里的“Network”面板看请求和响应一目了然报错了先看这里。4.3 常见运行报错与排错顺序我把这套项目从启动到跑通最常见的几个报错整理成一张表碰到问题先对着查一遍省得折腾一晚上。报错现象可能原因处理方式后端启动时报Access denied for userMySQL 用户名/密码不对核对 application.yml 里的数据库账号密码后端启动时报Unknown database数据库还没有创建或脚本没执行执行 SQL 脚本确认库名一致Failed to load resource: the server responded with a status of 404请求路径写错或接口没启动打开后端日志确认路径核对 RequestMapping 前缀wx.request:fail域名校验拦截或后端地址不可达开发者工具勾选“不校验合法域名”或真机改成局域网 IP前端请求报 401token 失效或没带重新走登录流程检查请求拦截器是否统一加了 header发布图片失败上传接口报 413文件过大前端压缩图片后端调大上传大小限制spring.servlet.multipart列表加载慢接口没有加索引分页没生效排查 SQL给分类、标题字段加索引确认 pageSize 传参排错的核心心法就一条从前到后逐层定位。前端页面报错先在开发者工具 Console 面板看 JS 报错信息然后看 Network 里是哪个请求挂了根据请求的返回信息判断问题出在前端还是后端后端接口报错看后端控制台的异常堆栈从第一行 exception 类型入手Google 搜索一下基本都是现成答案。我见过太多同学调试项目时看到报错先截图发群里“为什么失败了”连日志都没翻一眼。自己动手读日志顺着报错往上追追到源头你才真正学会调试这也是从“能跑通别人代码”迈向“能写自己代码”最重要的一步。5. 上线前的合规清单与避坑指南5.1 小程序审核的常见驳回点如果你不只是做课程设计而是真的想把菜谱小程序提交审核上线微信官方那关要注意几个高频驳回点踩中一个就打回重审来回折腾好几天。第一个是资质和类目问题。菜谱平台本质上属于“餐饮美食”或“生活服务”类目个人主体注册的小程序在很多类目上权限有限。如果你发布的内容涉及“饮食指导”“健康建议”等边界功能甚至可能需要额外资质比如食品经营相关证明。我的建议是个人学习项目就别硬冲上线做出来能真机演示已经足够交作业真要上线先研究清楚当前微信公众平台的类目政策和资质要求。第二个是用户协议与隐私政策。只要你采集了用户头像昵称微信授权登录就必然会拿到就必须在小程序“设置”里配置用户隐私保护指引并且在应用内提供用户协议、隐私政策文本链接。微信通过wx.getPrivacySetting和隐私弹窗机制强制了这件事漏掉这一环审核一拒一个准。第三个是内容安全问题。UGC 平台不是发什么都行的菜谱也一样有用户发布的内容涉及违禁词、广告导流平台要尽到审核义务。做到基础防护至少有这几步注册时接入微信风控发布时做敏感词过滤可以用开源词库或者调第三方文本审核设置用户举报入口后台提供删除和下架功能。这些在毕设源码里不一定都有但你自己加进去答辩就是个加分项。5.2 图片与流量的隐性成本很多人上线以后才发现最花钱的不是服务器租金是图片流量和存储。一幅手机原图 5MB用户看 20 道菜的首页光下载图片就是 100MB。单个用户一个月刷下来几 GB 流量服务器带宽完全扛不住云厂商的流量账单会让你怀疑人生。解决方案是“上传压一遍、下发再压一遍”。上传时后端调图片压缩工具把 5MB 压到 500KB 以内下发时如果用了 OSS/CDN还能配置图片处理规则比如缩略图裁剪、质量压缩按需再压。图片服务这块千万别省这是我见过所有内容型小程序最容易踩的运营成本大坑。如果你不想上 OSS项目前期还可以用本机磁盘目录保存图片。注意两点一是将上传目录单独映射成一个可访问的 URL 路径比如 Spring Boot 里配置静态资源映射二是别把上传目录放进src/main/resources下那样打包后文件会丢失。很多新手把图片传到项目目录里每次重新部署图片就没了这个坑我自己也掉过一次。还有个小细节图片文件名必须唯一。用户上传一张叫1.jpg的照片下一个用户又传一张1.jpg如果不加随机前缀或 UUID后传的会直接覆盖先传的数据库里记录还在图片却没了这个 bug 出现得非常隐蔽排查时让人头疼。5.3 用户体验与性能优化方向源码能跑通只是起点想拿出去展示或者进作品集还可以在体验上下几层功夫让整个项目区别于“学生管理系统”味。第一个方向是骨架屏与加载动画。菜谱列表的核心是图片图片在弱网环境下加载很慢界面上如果一片空白用户直接关掉。小程序提供了wx.createSelectorQuery和图片的binderror、bindload事件可以在图片加载完成前显示骨架占位加载完成后淡入淡出。这个细节做出来给人的“精致感”是完全不一样的。第二个方向是搜索流量的承接。微信小程序本身自带搜索入口你可以在“小程序后台 → 搜索配置 → 自定义关键词”里配置菜谱相关的关键词别人在微信搜索“家常菜做法”就有概率搜到你的小程序。这个功能不用写任何代码但能显著带来新用户是很容易被忽略的推广手段。第三个方向是收藏与浏览记录联动。“我的”页面里除了收藏列表还可以加一个“最近浏览”列表存到本地缓存wx.setStorage就行不占服务器用户觉得平台懂他。再往上一步可以做一个简单的推荐逻辑——根据用户收藏过的分类在首页优先推送同类菜谱用 SQL 里一个IN子查询就能实现效果还挺像那么回事。在我看来技术项目最怕的是“写完就完”多从用户视角抠几个体验细节哪怕只是让加载不再转圈、让点过的收藏变红、让搜索词有历史记录这些东西堆起来项目质感会直接上一个台阶。最后再分享一点个人的实践心得说实话我最早做这类小程序项目的时候也走过一段弯路——拿到一套源码先急着改界面把签名改成自己的名字换几张图片就觉得自己“做完”了。后来被一位前辈点醒源码的价值不在于让你拥有一个能跑的程序而在于帮你建立完整的产品和技术认知。你看懂了它怎么设计表结构就学会了 MySQL 建模看懂了它怎么写上传接口就明白了前后端对接的原理看懂了它怎么处理登录态就理解了会话管理。等这些东西都变成了你脑子里的东西再去做下一个项目不管换什么壳、挪什么领域内功都是通用的。如果你准备拿这套菜谱平台去参加比赛或者答辩我个人建议你先做一件事把某一个模块亲手删掉再亲笔重新写一遍。别嫌麻烦从“能跑通的源码”到“自己能写出来的源码”中间隔着的不是代码量是你对每个文件存在的理由是否真正理解。删除——重写——对比这一步比看十遍源码都有用。最后再送一个小技巧做这类内容社区项目提前准备好“10 道菜以上的真实数据”会让演示效果好非常多。我见过无数人演示时列表空空如也像个待开业的餐厅整个答辩现场气氛降到冰点。你提前把数据灌进去页面一打开就是满满当当的菜那份“真实感”是评委最吃的一套。