家庭大厨微信小程序开发实战：Spring Boot + MySQL 前后端分离与避坑指南-北京尧图网络

简介面向高校软件、计算机等专业毕业设计的Java微信小程序资源包围绕“家庭大厨”场景完整覆盖需求分析、可行性分析、系统设计、数据库设计等开发全流程。资源包内含可运行源码、MySQL数据库脚本、开题报告、论文、答辩PPT及使用说明管理员端提供个人中心、店铺管理、菜品信息与分类管理、购买菜品管理、订单行管理等模块借助SSM框架与微信开发者工具实现前后端分离的稳定管理方案。包体共1251个文件压缩包大小17.31MB主要文件类型包括java后端逻辑源码、vue前端页面、wxml/wxss微信小程序界面、js交互脚本、sql数据库脚本以及png/jpg界面截图目录层级清晰便于按模块查阅与二次开发。目前已有98人学习浏览适合需要快速搭建微信小程序毕业设计项目、理解SSM整合流程或参考论文结构的学生使用。资源附带完整文档与说明可大大缩短选题、编码与论文撰写的准备周期。1. 家庭大厨微信小程序到底在解决什么一个被重复造轮子的真实场景每年毕业季微信小程序 Java 后端的组合都会出现在大量计算机专业课题里家庭大厨这个选题切中的是“今天吃什么”这个高频痛点菜谱浏览、分类筛选、食材清单、收藏管理。把这套业务做成小程序前端 Java 后端 MySQL 数据库的完整闭环恰好覆盖了课堂里学过但没串起来的全部知识点——你不是在写一个 CRUD 作业而是在搭一个前后端真正联调过的可运行系统。免费提供全套 java 开源毕业设计源码这个信息点意味着项目拿到手是完整工程而不是碎片代码数据库脚本、开题报告、论文、PPT 都齐。这对两类读者最有用一类是正在准备课程设计或毕业设计的学生需要一套能讲清楚前后端交互逻辑的完整案例另一类是刚开始学小程序开发、想少走弯路直接看完整工程怎么组织的入门者。下面按我实际带项目时常走的一条线来讲先把架构和数据库立住再做小程序端再写 Java 接口最后聊真正跑起来才会踩到的坑。2. 技术选型和数据库设计为什么是 Spring Boot MySQL 微信小程序2.1 三端分离的结构小程序、后端服务、数据库各管什么先把这个项目的基础结构讲清楚。小程序端运行在微信开发者工具里WXML 负责页面结构WXSS 负责样式JS 逻辑里用 wx.request 发请求数据渲染靠 setData 驱动。Java 后端基于 Spring Boot 搭建向外暴露 RESTful 接口返回统一格式的 JSON数据库用 MySQL 存储用户、菜谱、分类、收藏这些业务数据。我一般会建议代码按这种包结构组织controller 层只做参数接收和结果返回service 层处理业务逻辑mapper 层负责和数据库交互entity 对应数据表。这样分层的好处不仅是代码整洁答辩时老师问“你的项目是怎么分层的”你能讲出设计思路而不是说“逻辑全写在 controller 里”。数据库连接池用 HikariCP 就行它是 Spring Boot 的默认选项配置少、性能好。如果用 MyBatis注意 mapper.xml 文件路径要配对很多人报 Invalid bound statement 就是因为 xml 没被扫描到。2.2 核心表的设计用户表、菜谱表、分类表、收藏表表结构是这个项目里最值得花时间的部分因为答辩时老师一定会检查数据库设计是否合理。最简可运行版本需要四张表用户表user、菜谱表recipe、分类表category、收藏表favorite。用户表字段id、openid、nickname、avatar_url、create_time。openid 是微信登录后拿到的用户唯一标识后端基于 openid 识别用户。菜谱表字段id、title、cover_image、ingredients、steps、cook_time、difficulty、category_id、create_time。ingredients 和 steps 用 TEXT 类型存长文本steps 也可以存 JSON 数组前端解析后逐步骤渲染。分类表字段id、name、sortsort 用于控制分类展示顺序。收藏表是典型的关联表user_id 和 recipe_id 做联合唯一索引防止同一条菜谱被重复收藏。这里有一个容易犯的设计错误把用户、菜谱、收藏全塞进一张表用逗号分隔 id 来存收藏列表。图省事的后果是取消收藏时要去字符串里做替换非常别扭。该拆的表一定要拆这是关系型数据库的基本功也是论文里数据库设计章节能写满两页的素材。2.3 建表 SQL一份可以直接跑起来的初始化脚本建表语句不用写得很花哨但字段类型、字符集、索引要合理。下面是我常用的建表结构CREATE DATABASE IF NOT EXISTS family_chef DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci; USE family_chef; CREATE TABLE user ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, openid VARCHAR(64) NOT NULL, nickname VARCHAR(64) DEFAULT , avatar_url VARCHAR(255) DEFAULT , create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE category ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, name VARCHAR(32) NOT NULL, sort INT DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE recipe ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, title VARCHAR(128) NOT NULL, cover_image VARCHAR(255) DEFAULT , ingredients TEXT, steps TEXT, cook_time INT DEFAULT 0 COMMENT 单位分钟, difficulty TINYINT DEFAULT 1 COMMENT 1简单 2中等 3困难, category_id INT UNSIGNED DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category_id (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE favorite ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, user_id INT UNSIGNED NOT NULL, recipe_id INT UNSIGNED NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_recipe (user_id, recipe_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;说明几个设计理由。字符集选 utf8mb4因为它支持 emoji 表情用户昵称和菜谱步骤里很可能有表情符号utf8 字符集会直接报错。openid 加唯一索引微信登录时同一用户重复写入会被数据库拦截比先查后插更稳。recipe 表的 category_id 加普通索引因为“按分类浏览菜谱”是最高频的查询条件。cook_time 用 INT 而不用 VARCHAR这样后端可以做“小于 30 分钟”的范围筛选用字符串存的话比较和排序都会变成字符串逻辑结果完全不对。3. 小程序端实现从创建项目到跑通首页列表3.1 项目结构和全局配置app.json、app.js、工具类拿到小程序端代码后先看三个核心文件。app.js 里做全局初始化app.json 配置页面路径和窗口样式还有一个关键配置是 request 的合法域名。开发阶段可以在微信开发者工具的“详情-本地设置”里勾选“不校验合法域名”但发布上线时小程序后台必须配置 HTTPS 的 request 合法域名。开发阶段用 http://localhost:8080 能跑通部署后就要换正式域名和证书。公用请求方法我一般封装成一个 request.js 文件统一处理 baseUrl、错误码和 token。很多项目实例里每个页面都写一遍 wx.request数据多了以后维护成本很高。下面是常用的封装写法const BASE_URL http://localhost:8080/api; function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method, data, header: { Content-Type: application/json }, success(res) { if (res.data.code 200) { resolve(res.data.data); } else { reject(res.data.msg); } }, fail(err) { reject(err); } }); }); } module.exports { request, BASE_URL };封装的价值在于全项目所有请求走同一个出口后端接口统一返回 { code, msg, data } 结构前端就能只关心业务数据。后续要加 token、加全局 loading 提示都只需要改这一个文件。BASE_URL 建议单独写在一个配置里不要每个页面复制一份否则换服务器 IP 时要全局替换容易漏。3.2 首页列表和分类切换setData 驱动视图更新首页是用户打开小程序看到的第一个界面典型结构是顶部横向分类 tab下面是菜谱卡片列表。整个数据流是onLoad 请求分类接口拿到分类列表后默认选中第一个分类再请求该分类下的菜谱列表。代码上需要维护两个关键状态当前选中的分类下标和列表数据。点击分类时同时更新这两个值Page({ data: { categories: [], currentIndex: 0, recipes: [], loading: false }, onLoad() { this.loadCategories(); }, loadCategories() { const { request } require(../../utils/request.js); request(/category/list).then(list { this.setData({ categories: list }); if (list.length 0) { this.loadRecipes(list[0].id); } }); }, loadRecipes(categoryId) { this.setData({ loading: true }); const { request } require(../../utils/request.js); request(/recipe/list?categoryId${categoryId}).then(list { this.setData({ recipes: list, loading: false }); }); }, onTabChange(e) { const index e.currentTarget.dataset.index; const category this.data.categories[index]; this.setData({ currentIndex: index }); this.loadRecipes(category.id); } });两个细节要注意。第一切换分类后旧列表数据可能还在页面上闪现优先在 loadRecipes 开头把 recipes 清空或把 loading 置为 true体验差异很大。第二setData 是异步的不要指望数据更新后立即从 this.data 里读到最新值后续逻辑应该放在 setData 的回调或 then 里。3.3 详情页和收藏按钮单选框筛选与收藏状态回显详情页从首页列表跳转进入使用 wx.navigateTo 携带菜谱 id。进入详情后需要两个接口菜谱详情和当前用户是否已收藏。后者通常合并到详情接口里返回一个 favorited 字段省一次请求。收藏按钮交互采用乐观更新策略点击后先改变 UI 状态再调接口接口失败再回滚。如果等接口返回才改 UI网络慢时用户连点两次会发出两个请求反而产生重复数据。难度筛选场景会用到微信小程序的单选框组件。筛选条件包括简单、中等、困难三档使用 radio-group 包裹 radio 组件通过 value 区分选项。bindchange 事件里 e.detail.value 拿到的是选中的值把这个值拼进请求参数传给后端就能实现按难度过滤。注意 radio 组件在自定义样式时需要用 label 包裹才能扩大点击区域不包的话用户只能点中圆点在小屏设备上很容易点不中。3.4 顶部导航栏高度适配自定义导航栏的参数计算如果项目用的是默认导航栏标题栏高度由微信自动处理完全不用操心。但如果首页要做自定义的渐变背景或圆角搜索框就得把导航栏设为自定义此时必须手动适配状态栏高度。常见做法是在 app.js 里用 wx.getSystemInfoSync 获取 statusBarHeight再用 wx.getMenuButtonBoundingClientRect 获取胶囊按钮的布局信息两者相加得到导航栏总高度挂到全局供页面使用。关键参数是胶囊按钮的 top 和 height不同机型的差异很明显Android 和 iPhone 刘海屏的数值不一样写死一定会出问题。调试时可以临时在页面 onLoad 里打印这两个接口的返回值看自己设备上的实际数据。用真实坐标计算出来的导航栏高度在不同机型上都能正确吸附这是比任何经验值都可靠的做法。4. Java 后端实现接口设计、登录鉴权与数据返回4.1 统一返回结构code、msg、data 的约定前后端联调时最痛苦的是每个接口返回格式都不一样前端要写一堆 if 分支处理不同结构。所以后端第一个要定下的规范就是统一返回类所有 controller 都返回同一结构前端只需要解析一种格式。约定如下code 为 200 表示成功500 表示业务错误401 表示未登录。前端 request.js 里判断 code 不等于 200 就走 reject 分支统一提示。这个约定在答辩时也说得通“所有接口统一返回格式便于前端统一处理和后续扩展”。统一返回类的核心代码public class ResultT { private Integer code; private String msg; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.setCode(200); r.setMsg(ok); r.setData(data); return r; } public static T ResultT error(String msg) { ResultT r new Result(); r.setCode(500); r.setMsg(msg); return r; } // 省略 getter/setter }success 和 error 做成静态工厂方法controller 里写一行 return Result.success(list) 就完成返回。泛型的使用让 data 字段的运行时类型由具体调用决定前端拿到 JSON 直接使用即可不需要额外做类型转换。异常处理的场景下还可以加一个 error 重载接收异常对象把异常消息透传给前端调试用。4.2 Controller 层和 Service 层接口只做转发业务写在 service 里Controller 的职责是接收参数、做最基础校验、调用 service、返回结果不能把 SQL 和业务逻辑堆在 controller 里。以菜谱列表接口为例controller 接收 categoryId 和分页参数调用 service 查询包一层 Result 返回。RestController RequestMapping(/api/recipe) public class RecipeController { Autowired private RecipeService recipeService; GetMapping(/list) public ResultListRecipeVO list( RequestParam(required false) Integer categoryId, RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer size) { return Result.success(recipeService.listByCategory(categoryId, page, size)); } GetMapping(/detail) public ResultRecipeDetailVO detail(RequestParam Integer id) { return Result.success(recipeService.getDetail(id)); } PostMapping(/favorite) public ResultVoid favorite(RequestParam Integer userId, RequestParam Integer recipeId) { recipeService.toggleFavorite(userId, recipeId); return Result.success(null); } }两个设计理由要说明。第一返回前端的是 VO 对象而不是数据库实体VO 里可以附加 favorited 等展示字段不污染表结构第二favorite 接口用 POST 而不是 GET因为它改变了服务端数据状态语义更规范也避免部分场景下请求被缓存。Service 层负责具体逻辑toggleFavorite 的流程是先查收藏表是否存在记录存在则删除不存在则插入。判断逻辑放 service 而不放 controller是因为 service 可以复用于其他入口controller 只是 HTTP 层。4.3 微信登录流程code 换 openid再生成自定义 token微信小程序登录链路是wx.login 拿到临时 code传给后端后端用 code 加 appid 和 secret 请求微信官方接口换回 openid。后续业务请求不再传 code而是用服务端自己颁发的 token 鉴权。常见做法是首次登录时用 openid 查用户表不存在就插入新用户存在就直接返回。同时生成一个 UUID 作为 token 存到 user 表前端后续请求在 header 里带 token后端用拦截器解析 token 并注入 userId。毕业设计不强制引入 redistoken 存在 user 表的 token 字段里简单够用。如果老师追问 token 生命周期你要能说清楚 token 什么时候过期、用户退出后如何失效、重新登录后旧 token 是否要作废这几个问题答上来就不会被问倒。登录接口的时序是wx.login 获取 code - 小程序端把 code 发给后端 - 后端请求微信接口换取 openid - 查库或建新用户 - 生成 token 返回 - 小程序把 token 存到本地 storage后续请求带上。核心点在第一步和第二步code 是临时凭证且有效期很短必须实时获取不能缓存复用。4.4 分页查询手写 LIMIT 的写法与参数换算菜谱列表超过几十条以后不分页会导致两个问题首次加载慢、流量浪费。常见做法有两种引入 PageHelper 插件或手写 LIMIT。PageHelper 的坑在于多表 join 或复杂 count 时生成的 count 语句可能出错。手写 LIMIT 更可控适合毕业设计这个规模。public ListRecipe listByCategory(Integer categoryId, int offset, int limit) { return recipeMapper.selectByCategory(categoryId, offset, limit); }select idselectByCategory resultTypecom.familychef.entity.Recipe SELECT id, title, cover_image, ingredients, steps, cook_time, difficulty, category_id, create_time FROM recipe where if testcategoryId ! null AND category_id #{categoryId} /if /where ORDER BY create_time DESC LIMIT #{offset}, #{limit} /selectLIMIT 后面的两个参数含义是“从第几条开始”和“取多少条”不是页码和总数。前端传 page 和 size后端要手动换算 offset (page - 1) * size。这里最常见的错误是把 page 直接当作 offset 传入导致第二页数据和第一页重叠。另外标签的判断让 categoryId 可传可不传不传时返回全部菜谱这是分类筛选和全部列表复用同一个接口的关键。4.5 CORS 跨域配置本地调试必踩的一关小程序开发者工具里的 wx.request 不受浏览器同源策略约束但如果你在 HBuilderX 内置浏览器里调试网页版或者用其他 HTTP 客户端测试跨域问题就会出现。Spring Boot 解决跨域的方式通常是在配置类里注册 CorsFilterConfiguration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }这个配置允许所有来源、方法和请求头跨域开发阶段够用。上线前建议把 addAllowedOriginPattern 换成实际域名否则任何网站都能调用你的接口存在安全隐患。这个坑的特点是请求发出去了但拿不到响应控制台报 Access-Control-Allow-Origin 错误。注意 setAllowCredentials(true) 和 addAllowedOriginPattern(*) 同时使用时部分浏览器会拦截带凭证的请求需要把 * 改为具体域名才能正常工作。5. 避坑与排查把整套项目跑通时最常见的 5 个问题5.1 小程序真机预览白屏模拟器却正常现象微信开发者工具里一切正常一真机预览就白屏或所有接口失败。原因真机上 wx.request 走的是正式网络路径必须使用 HTTPS 且域名已在小程序后台配置。开发者工具里可以勾选“不校验合法域名”真机上没有这个开关。解决开发阶段可以用开发版加“不校验合法域名”临时调试正式预览必须把后端部署到带 HTTPS 的服务器并把域名配置进小程序后台的 request 合法域名列表。另外真机上 BASE_URL 不能写 localhost要写服务器外网 IP 或域名localhost 指向的是手机自身。5.2 MySQL 连接报 Access denied 和 Public Key Retrieval现象后端启动报 Access denied for user或连接时提示 Public Key Retrieval is not allowed。原因前者是账号密码或 host 权限配置错误后者是 MySQL 8.0 默认的 caching_sha2_password 认证方式和旧版驱动不匹配导致的。解决检查 application.properties 里的 url、username、password确认数据库用户有远程访问权限。第二个问题在 JDBC url 后加 allowPublicKeyRetrievaltrueuseSSLfalse 通常能解决也可以把 MySQL 用户的认证方式改为 mysql_native_password。注意改完认证方式要刷新权限或重启 MySQL 服务才生效。5.3 MyBatis 报 Invalid bound statement现象运行时报 org.apache.ibatis.binding.BindingException: Invalid bound statement (not found)但 Java 代码没有编译错误。原因mapper 接口和 mapper.xml 没有正确关联。常见情况是 xml 文件没有放在 mapper 接口同包路径下或 application.properties 里没有配置 mapper-locations。解决在配置里加 mybatis.mapper-locationsclasspath:mapper/*.xml然后确认 target/classes 目录下确实有编译后的 xml 文件。如果用 IDEAxml 文件可能没被打包进 target 目录需要在 pom.xml 里配置 resources 节点强制包含这个坑的隐蔽程度很高因为本地跑的时候有时候能通过 IDE 的编译策略正常加载打包部署时就翻车。5.4 图片能显示在数据库里小程序页面却破图现象菜谱封面图地址存在数据库里小程序端有的图片能显示有的显示为裂图。原因图片地址存的是相对路径如 /upload/xxx.jpg小程序 image 组件的 src 需要完整 URL另外本地文件图片在小程序里访问受限。解决图片入库时统一存完整 URL包含协议、域名和路径。开发阶段可以复用本地静态资源但发布前必须把图片上传到对象存储服务用返回的 CDN 地址更新数据库。这个改动越早做越好等菜谱数据攒了几百条再批量改会很痛苦而且论文里的截图如果用的是本地路径答辩时演示一换机器就全挂。5.5 接口返回正常页面数据不刷新现象console 里能看到请求返回了数据但页面还是空白或显示旧数据。原因最常见的两种一是请求回调里忘了 setData数据赋给了临时变量二是请求写在 Page 外部模块里回调中的 this 指向的不是 Page 实例。解决Page 内部建议用箭头函数写回调或者在 onLoad 开头 const that this回调里统一用 that.setData。封装 request.js 后用 Promise 的 .then 回调相对干净避免 this 丢失。代码里不要出现 this.data.xxx res.data 这种直接赋值它不会触发视图更新。判断数据是否生效可以临时在 setData 后加 console.log(this.data.xxx) 打印验证。6. 进阶用法把静态菜谱列表做成搜索和简单推荐跑到这里整条链路已经闭环。如果想在论文或答辩里进一步体现工作量可以做两块增强功能关键词搜索和基于收藏行为的简单推荐。关键词搜索的落地方式是后端模糊查询SQL 用 LIKE %关键词% 同时匹配 title、ingredients、steps 三个字段前端在首页顶部加一个搜索框输入后调用搜索接口。注意 LIKE 查询在数据量变大后性能下降明显但毕业设计数据量下完全够用答辩时诚实说明这一点反而加分。另一个细节是搜索接口的参数要做空值校验关键词为空时直接返回全部列表或空列表不要拼接出奇怪的 SQL。推荐逻辑可以设计成“用户收藏过的分类作为兴趣标签”统计用户收藏菜谱所属分类的出现次数取前三名再按这些分类拉取菜谱如果用户没有收藏记录回退到按时间排序的最新菜谱。这个逻辑不算复杂但能让你在答辩时讲清楚“推荐不是凭空来的是基于用户行为的规则推断”而不是说“这段代码是网上抄的”。最后说一个个人习惯改动代码前把当前能跑通的版本在 Git 里打一个 tag。我做这个项目调试 CORS 时改崩过一次环境花了三个小时才恢复从那以后每次都先 commit 再动手。这个项目也一样每跑通一个功能就提交一次翻车随时有后悔药。现阶段数据量小不追求高并发和高可用重点是把业务闭环跑顺、把技术点讲透做到这两点答辩基本就稳了。希望帮到你。本文还有配套的精品资源点击获取

家庭大厨微信小程序开发实战：Spring Boot + MySQL 前后端分离与避坑指南

相关推荐

从记忆型AI到可开工Agent：个人智能体落地实践与踩坑记录

749张行李箱图像训练YOLO模型：小样本目标检测实战指南

从“记得”到“能干”——个人AI Agent落地实践与架构解析

更多资讯

YOLOV9安全帽与反光背心检测：数据集构建与训练全流程指南

DHCP服务器设计与实战：从IP分配到网络智能中枢

Zed AI代理驾驶舱实测：从Redux到Zustand的智能重构实践

Python GIL深度解析：全局解释器锁的原理、影响与绕开方案

Cline 接入 Agnes AI 完整教程：从密钥配置到参数调优

AI工程全景地图：从模型到系统落地，六大能力域与工程实践解析

今日更新

Play Framework 迁移指南：移除 GlobalSettings，全面转向依赖注入（Scala 与 Java）

Numba 类型推断机制详解：从 Numba IR 到编译期类型重建的完整原理与实践

企业级项目dragonballz_e159-1的技术架构与实现方案

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？