苍穹外卖

背景:
外卖是餐饮行业最高频的消费场景之一,典型形态是"商家管理端 + 用户点餐小程序"双端协同。本课程实战项目以美团外卖类平台为业务蓝本,从 0 到 1 搭建一套完整的外卖点餐系统。
目标:
业务目标:打通“用户点餐 → 微信支付 → 商家接单 → 派送完成”的完整交易闭环,并为商家提供经营数据统计能力;
技术目标:用企业主流技术栈(Spring Boot + MyBatis + Redis + MySQL)完整实现一个单体后端,覆盖鉴权、缓存、支付、实时消息、定时任务、报表导出等典型后端场景。
软件功能、核心功能模块介绍
系统分两端,后端共 18 个 Controller、70 个 REST 接口:
|端 | 模块 | 功能点 |
|管理端(Web 后台) | 员工管理 | 登录、增删改查、启用/禁用
|分类管理 | 菜品/套餐分类的增删改查、启停 |
|菜品管理 | 菜品 + 多口味维护、图片上传、上下架 |
|套餐管理 | 套餐 + 包含菜品维护、上下架 |
|订单管理 | 接单、拒单、取消、派送、完成 |
|数据统计 | 营业额统计、用户统计、订单统计、销量 Top10、运营数据 Excel 导出 |
|工作台 | 今日营业额/有效订单/完成率/客单价/新增用户、订单/菜品/套餐总览 |
|店铺设置 | 营业/打烊状态切换 |
|用户端(微信小程序) | 用户模块 | 微信授权登录(新用户自动注册) |
|点餐模块 | 分类/菜品/套餐浏览、购物车 |
|地址管理 | 收货地址增删改查、默认地址 |
业务流程、功能路径描述：
1、核心链路:用户点餐下单支付(功能路径最完整的一条)
小程序授权登录(code → openid → 自动注册 → 签发JWT)
→ 浏览菜品/套餐(按分类+口味,列表走Redis缓存)
→ 加入购物车
→ 提交订单(校验地址、购物车非空、店铺营业状态,多表写入走事务)
→ 调微信支付下单(API V3,返回拉起支付参数)
→ 用户完成支付
→ 微信服务器回调 /notify/paySuccess(验签解密)
→ 订单状态:待付款 → 待接单,WebSocket推送商家端"来单提醒"
→ 商家接单 → 派送 → 完成
(旁路:待付款超15分钟,定时任务每分钟扫描自动取消)
2、商家经营链路:
登录工作台查看今日核心指标(营业额/有效订单/完成率/客单价/新增用户)
→ 数据统计页查看任意起止日期的营业额/用户/订单趋势、销量Top10
→ 一键导出最近30天运营数据Excel报表
3、菜品上架链路:
上传图片(OSS,UUID重命名) → 维护分类/口味/价格/售卖状态
→ 上下架后清理Redis中对应分类的菜品缓存,避免C端读到旧数据

我独立完成了"苍穹外卖"后端全部模块。这是一个模拟真实外卖业务的点餐系统,分管理端和用户端两端。管理端给商家用,包括员工管理、菜品/套餐管理、订单管理,以及工作台和数据统计——支持营业额、用户、订单、销量 Top10 四类统计图表和 Excel 报表导出;用户端是微信小程序,包括微信登录、菜品浏览、购物车、下单微信支付、历史订单。后端用 Spring Boot 4.0.5 + MyBatis + MySQL + Redis 搭建,三个 Maven 模块分层开发,共 18 个 Controller、70 个接口、约 6000 行代码。核心交易链路是:微信支付回调成功后,通过 WebSocket 给商家端推送来单提醒;超时未支付订单由定时任务自动取消;菜品列表用 Redis 缓存。我印象比较深的坑有三个:统计接口的逐日查询性能问题、支付回调的本地调试问题、以及 Redis 缓存一致性问题,下面可以展开讲。
1、统计接口的查询性能(N+1 问题)
坑:营业额/用户/订单统计需要按天返回曲线数据,逐日循环查询意味着查 30 天要发 60 次 SQL,天数越多接口越慢。
方案:抽象出 `sumByMap`/`countByMap` 动态 SQL(Map 参数 + `` 动态条件),一套 SQL 同时服务工作台和统计模块;销量 Top10 用 `order_detail JOIN orders + GROUP BY + LIMIT` 一条 SQL 完成。改进方向:用 `DATE(order_time) GROUP BY` 一次查出每日数据,查询次数可从 O(天数) 降到 1 次。

2、微信支付回调本地无法调试
坑:微信支付成功后微信服务器要回调我们的接口,但本地 localhost 微信访问不到,开发阶段无法闭环调试。
方案:用 cpolar 内网穿透把本地服务映射成公网 https 回调地址,配置到 `notifyUrl`;回调接口用微信支付 SDK 完成验签解密,更新订单状态后通过 WebSocket 实时推送给商家端。

3、Redis 缓存一致性问题
坑:C 端菜品列表按分类缓存到 Redis,管理端新增/删除/修改菜品后,C 端仍读到旧数据。
方案:管理端菜品变更后,按 `dish_*` 的 key 模式删除对应缓存,下次查询重建;店铺营业状态读写都走 Redis,保证管理端切换后 C 端立即生效。