南瑾i作为一个前后端都写过不少东西的开发者，我去年帮师弟完成了一个基于SpringBoot的校园订餐微信小程序项目，从技术选型、数据库设计到最终部署，整个过程踩了不少坑，也沉淀了一些可复用的经验。今天就把这套完整的设计思路、核心实现和部署要点整理出来，希望能给正在做类似课设、毕设，或者想入门微信小程序开发的朋友一些参考。
这个项目本身不算复杂，但胜在功能链路完整，覆盖了一个典型业务系统从用户端到管理端的所有关键环节——小程序端负责用户点餐、购物车、订单管理，后端SpringBoot应用处理业务逻辑、权限校验和微信登录，数据库则存储用户、菜品、订单、评价等核心数据。换句话说，它足够让你摸清一个真实商业项目的基本骨架。
如果你正打算从零开始做一个「SpringBoot + 微信小程序」的全栈项目，或者接手一套现成的源码一知半解，这篇内容就是为你准备的。
1. 项目整体设计与技术选型
1.1 为什么是SpringBoot + 微信小程序
先说后端。SpringBoot在Java生态里几乎是事实标准，它最大的价值是让很多人头疼的Spring配置变得极简。以前搭一个SSM项目，光XML配置文件就要写半天，引入依赖还得自己处理版本冲突；SpringBoot则通过自动配置把这些重复劳动干掉了。你在项目里写上spring-boot-starter-web、mybatis-plus-boot-starter，几行代码就能把Web服务跑起来，这对开发效率和维护来说价值巨大。
再说前端。校园订餐这件事，用户核心诉求是“打开就能用、用完就关”，微信小程序完美命中了这个场景。它不需要下载安装，扫码或搜索即可打开，微信生态内还自带支付、登录、订阅消息等基础设施。跟开发原生App相比，小程序省去了应用市场审核、版本更新的麻烦；跟做H5网页相比，小程序的API能力更接近原生体验，比如获取用户定位、调用微信支付、订阅消息推送。
这就是我推荐这套组合的根本原因：后端用SpringBoot快速搭服务，前端用微信小程序覆盖用户高频使用场景，二者通过RESTful API通信，分工清晰，适合开发周期有限的课程设计和毕业设计。
1.2 系统功能模块怎么划分
这套系统我建议分成两个核心端：用户端（小程序）和管理端（小程序内嵌或后台网页）。用户端面向学生群体，管理端面向食堂商家或系统管理员。所有功能模块围绕“点餐—支付—履约—评价”这条完整链路展开。
用户端核心功能包括：
- 微信登录：用户打开小程序，通过
wx.login获取临时code，后端调用微信接口换取openid，实现免注册登录。 - 浏览菜品：按分类展示菜品列表，支持搜索、查看菜品详情（图片、描述、价格、评分），菜品还可以打上“招牌推荐”之类的标签。
- 购物车：用户将菜品加入购物车，支持修改数量、删除、清空、结算。
- 提交订单：从购物车生成订单，选择配送地址（校园宿舍楼栋+门牌号）、备注口味偏好，提交后调用微信支付。
- 订单管理：查看当前和历史订单状态，包括待付款、待接单、配送中、已完成、已取消；订单完成后可进行评价和追评。
- 个人中心：管理收货地址、查看评价记录、联系客服等。
管理端（这里我用了一个独立的管理后台页面包在管理员的视角里）核心功能包括：
- 商家入驻/角色配置：管理员审核商家账号，分配对应食堂窗口。
- 菜品管理：上下架菜品、维护菜品种类和库存、设置每日特价。
- 订单管理：查看所有用户订单，接单、标记配送、完成订单等。
- 数据统计：展示今日订单量、营业额、热门菜品排行等基础运营数据。
一开始我差点把管理端做成一个独立的小程序，后来发现这样做有两个问题：一是小程序审核时如果涉及商家入驻、虚拟支付等内容，审核周期会拉长；二是管理端通常不需要高频移动操作，用后台管理系统管理起来效率更高，界面也更容易做出复杂的数据分析图表。所以最终我给管理端单独设计了一套基于Thymeleaf或者Vue的后台界面，这里就不展开讲了。
1.3 技术栈清单
整个项目我用到的核心技术栈如下：
| 层级 | 技术选型 | 说明 |
|---|---|---|
| 后端语言 | Java 8+（建议Java 11或17） | SpringBoot对这两个版本兼容极佳 |
| 后端框架 | SpringBoot 2.7.x 或 3.x | 2.7.x更稳，3.x要求JDK17+，按自己环境选 |
| ORM | MyBatis Plus | 单表CRUD不用写SQL，分页也封装的很好 |
| 数据库 | MySQL 5.7+ 或 8.0 | 8.0对JSON类型、性能优化更友好 |
| 缓存/分布式会话 | Redis（可选） | 用于缓存验证码、维持登录态、限流 |
| 鉴权方案 | JWT 或 Sa-Token | 无状态，适合前后端分离架构 |
| 前端框架 | 微信小程序原生 + Vant Weapp组件库 | 用原生+UI库，减少学习成本和兼容问题 |
| 接口文档 | Swagger / knife4j | 调试接口，写答辩文档时特别好用 |
| 部署 | Nginx + Docker（可选）或直接jar包 | 服务器资源紧张时直接java -jar即可 |
| 工具链 | Maven、Git、宝塔面板 | 简化部署，提升开发协作效率 |
这里需要特别说一个坑：曾经有同学图新直接用SpringBoot 3.x，结果很多老版本的MyBatis Plus和Spring Security还需要额外适配，反向踩了不少坑。如果是做课设或毕设，时间紧张的话建议直接使用SpringBoot 2.7.x，不用太纠结。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计与后端核心实现
2.1 核心表结构与关系设计
数据库设计是整个项目的根基，表结构设计好了，后面的业务代码就是水磨工夫。这套系统我最终设计了七张核心表，它们之间的联系可以用几句话梳理清楚：
- 用户表（user）：存储用户openid、昵称、头像、手机号、默认地址ID等。用户不需要注册，第一次微信登录成功后自动创建。
- 分类表（category）：存储菜品分类名称和排序值，比如“招牌套餐”“饮品甜点”“米饭简餐”。
- 菜品表（dish）：存储菜品名称、图片、描述、原价、现价、库存、是否推荐、所属分类。字段尽量拆细，像“辣度”“标签”这类可以用JSON存。
- 购物车表（cart）：以用户ID为维度记录购物车数据，菜品ID、数量、勾选状态、加购时间。这里要注意用
user_id + dish_id做唯一索引，防止同一菜品被反复插入生成多条脏数据。 - 订单表（orders）：存储订单编号、用户ID、总金额、配送地址、备注、订单状态、支付时间、接单时间、完成时间。订单编号建议用时间戳+随机数，避免直接暴露自增ID导致刷单风险。
- 订单明细表（order_detail）：存储每个订单涉及的菜品快照（菜品名称、图片、单价、数量），防止后续菜品下架导致历史订单无法追溯。
- 评价表（comment）：关联订单和菜品，用户可以打星、填写文字评论、上传图片。
在具体建表时，我有几个切身体会：
- 金额一律用decimal(10,2)，绝不用float，否则容易出现金额精度问题，比如订单总额显示成49.999999。
- 订单状态用int或tinyint，例如0待付款、1待接单、2配送中、3已完成、4已取消、5退款中，在代码里用常量或枚举去匹配，不要直接在业务里写死数字。
- 统一添加create_time、update_time、is_deleted字段，虽然有时候感觉冗余，但在统计和排查问题时非常有用。
2.2 小程序登录与鉴权方案
小程序端使用的登录流程是微信生态基本操作，但也是很多新手最容易搞不清楚的地方。
大致流程如下：
- 小程序端调用
wx.login()，获取一个临时凭证code，这个code有效期只有5分钟，只能使用一次。 - 小程序把这个code通过后端接口传给SpringBoot应用。
- 后端拿着这个code，配合小程序的AppID、AppSecret，向微信接口`https://api.weixi