周恰恰简历上出现“苍穹外卖”的项目已经不算新鲜事了，但我面试候选人时最常问的其实只有两句话：如果用户同时点了 5 次下单，你的系统会创建出几笔订单？如果支付回调晚到了 10 秒钟，订单状态到底该听谁的？能把这两个问题说得滴水不漏的人，比能背出一长串框架名字的人少太多了。苍穹外卖这个项目之所以值得从头到尾做一遍，是因为它看起来只是一个“点餐加配送”的业务系统，实际却把订单、支付、并发、缓存、权限和定时任务全部串在了一起。这篇复盘既是写给自己，也是写给正在拿这个项目练手、准备用它当求职作品的同学。
1. 苍穹外卖的需求边界：不是抄美团，而是画清楚外卖闭环
1.1 三类角色加上配送端，才叫真正的业务闭环
很多刚接触苍穹外卖的人，第一反应是把美团 App 的界面拆一遍：首页要有轮播图、分类、店铺列表，详情页要有评价、优惠、起送价。但照着这些功能做下去，很容易变成一个静态页面展示系统，后端只是照着页面堆 CRUD 接口。
我整理需求时先做了一件很朴素的事：把参与这笔外卖生意的人都列出来。最低限度要有四类使用方：
- 用户端：在小程序或 H5 上浏览菜品、加购物车、下单、支付、查看订单、申请售后。
- 商家端：维护门店信息、菜品和库存，接收新订单，执行接单、出餐、配货等操作。
- 配送端：骑手查看可抢订单、抢单、更新取货和送达状态。
- 平台管理端：对用户、商家、订单、活动、问题反馈做统一运营和管理。
把角色列出来后，主流程自然也就清楚了：商家上架菜品，用户浏览下单并完成支付，商家接单备餐，骑手取餐配送，最后用户确认收货。苍穹外卖真正难的地方，并不在于界面多好看，而在于这个流程里的每一个状态跳转都要稳定可靠。用户端下单之后商家能不能立即看到、商家接单之后骑手能不能及时抢到、支付结果和订单状态在并发下会不会错乱，这些才是项目核心。
1.2 MVP 范围怎么定，砍需求的标准是什么
做苍穹外卖这类项目时，最大的坑是“什么都想要”。我见过有人第一版就把拼团、秒杀、好友代付、骑手实时轨迹全部规划进去，结果数据库设计了二十多张表，最后连完整跑通一单的能力都没有。
我在第一个版本里给自己定了三条硬性原则：
- 能跑通完整交易闭环的功能必须最先做，例如菜品、购物车、订单、支付、配送状态。
- 和钱相关的能力必须做完整，例如支付回调、订单超时关闭、退款、对账。
- 只带来流量不直接产生交易结果的功能可以往后放，例如社区种草、直播探店、复杂营销玩法。
按这个标准，第一版苍穹外卖的功能清单聚焦在：用户地址管理、菜品分类与检索、购物车、下单支付、商家接单、骑手抢单配送、订单详情、售后申请、后台数据看板。优惠券和秒杀这类功能虽然我也很想做，但它们的复杂度集中在“防止被薅羊毛”和“防止超发”，不是核心流程必须依赖的，于是被我统一挪到了二期。
需求边界一旦划清楚，后面数据库怎么建、定时任务开几个、接口如何拆，都会变得顺理成章。先做完整闭环，再谈横向扩展，这是我在这个项目上得到的第一条经验。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型复盘：为什么我放弃了微服务架构
2.1 单体多模块起步，比一步拆成微服务省心太多
决定技术栈之前，我先问了自己一个问题：这个项目的用户量到底有没有到必须水平扩展的程度？答案很清醒：没有。
所以我最终选择了单体应用 + 模块化拆分的方案。也就是说，代码在工程上是拆开的，比如 user 模块、product 模块、order 模块、payment 模块、dispatch 模块、stats 模块，但最终被打成一个 Java 工程、部署在同一组实例上。
这样做的理由非常实际。微信小程序、商家后台、骑手 App 共用同一套后端接口，如果一开始就把订单服务、支付服务、用户服务拆成三个独立进程，光是跨服务调用的鉴权、分布式事务、日志追踪就足够把开发进度拖慢一倍。而单体多模块依然可以保持清晰的业务边界，未来万一真的需要把支付或订单模块独立部署，代码层面的迁移成本也会比“所有逻辑揉在一个 service 里”低很多。
2.2 核心组件清单与选型逻辑
苍穹外卖这种业务，最核心的基础设施其实不需要太多。
| 组件 | 用途 | 我选择它的原因 |
|---|---|---|
| MySQL 8.0 | 存储用户、订单、菜品、商家等核心数据 | 关系型数据、事务能力强，InnoDB 支持行锁和条件更新，适合订单状态流转 |
| Redis | 验证码缓存、登录态、菜品缓存、接口幂等、抢单临时状态 | 性能高，支持 SETNX、Lua 脚本，能解决高并发下的重复与原子性场景 |
| RabbitMQ | 订单超时延迟消息、支付结果异步通知、商家接单推送 | 延迟队列能解决“15 分钟未支付自动关单”，消息确认机制保证不丢单 |
| XXL-Job 或 Spring Task | 定时统计报表、超时订单兜底扫描、历史数据归档 | 和业务代码结合简单，能覆盖大多数定时场景 |
| MinIO 或阿里云 OSS | 菜品图片、商家资质图片存储 | 对象存储开箱即用，不额外引入复杂文件系统 |
| Docker 与 Docker Compose | 在开发环境一键启动 MySQL、Redis、MQ | 保证本地环境和线上环境一致，减少“在我机器上明明能跑”的问题 |
有人会问，为什么不用 Elasticsearch 做菜品搜索？这是因为第一版菜单搜索量没那么大，MySQL 用索引覆盖也能支撑。Elasticsearch 确实能提供更好的分词搜索体验，但引入它意味着新增一套数据同步机制，比如用 Canal 订阅 binlog，或者业务代码双写。对苍穹外卖的体量来说，这套成本暂时收不回来。
2.3 前后端分离下的统一鉴权和接口约定
苍穹外卖有小程序端、商家 Web 端、骑手 App，必然会要求同一套后端接口支持多端登录。我统一采用 JWT 令牌，把 userId、role、租户标识写进 token 的 claims 里，后端通过拦截器解析请求头中的 token，再根据路径前缀做权限控制。
具体接口规划是：
/api/user/**：用户端接口，包括注册登录、地址、购物车、订单、支付。/api/merchant/**：商家端接口，包括菜品管理、订单处理、营业数据。/api/admin/**：平台运营接口，包括用户管理、商家审核、订单查询。/api/dispatcher/**：骑手端接口，包括抢单列表、接单、更新配送状态。
这里有一个容易被忽略的细节：JWT 的 secret 不能硬编码在代码里，更不能提交到 Git，否则任何人拿到 secret 都能伪造管理员令牌。我在开发环境用配置中心或环境变量注入，并给不同角色分配独立的权限校验注解，避免用户端接口直接越权访问商家端数据。
3. 并发设计避坑：重复下单、支付幂等、骑手抢单
3.1 防止重复下单：数据库唯一键比分布式锁更让人安心
外卖业务里，用户对“提交订单”按钮连点几下是非常常见的行为。只在前端做按钮 loading 远远不够，因为移动端网络波动会导致请求重试。做一个良好的后端防重设计，要把“操作只能成功一次”落在后端。
我在苍穹外卖里采用了接口令牌加唯一订单号的双保险方案。
第一步，用户准备提交订单时，先调用获取下单令牌的接口。后端在 Redis 里写入一个短时 key，比如 order:token:{userId}，同时生成唯一的 token 返回给前端。这个 key 的有效期设成 3 分钟，足够用户完成整个下单流程。
第二步，前端提交订单时必须带上 token。后端在处理请求的第一行使用 Redis 的 SETNX 指令尝试占用这个 token：
java复制Boolean acquired = redisTemplate.opsForValue()
.setIfAbsent("order:token:" + userId, token, Duration.ofMinutes(3));
if (!Boolean.TRUE.equals(acquired)) {
throw new BizException("订单正在提交中，请勿重复操作");
}
如果 SETNX 返回 false，说明已经有一个请求在占用这个 token，第二个请求直接拒绝。但这里还有一个漏洞：如果第一个请求在事务提交前进程突然重启，Redis 里的 token 已经被占用了，用户需要重新获取 token。所以我在数据库层面又加了一道兜底，给订单表的 order_no 字段建了唯一索引。就算应用层防重没有拦住，数据库也会因为唯一键冲突而拒绝插入第二笔订单。
这道“Redis 防重 + 唯一索引兜底”的组合，是苍穹外卖给我上的第一堂高并发课：程序防重是优化，数据库约束才是最后的底线。
3.2 支付回调幂等：状态机不让订单乱翻跟头
用户支付完成之后，微信或支付宝服务器会异步发送回调通知。第三方支付回调有一个很折磨人的特点：同一个支付结果可能会被推送多次，而且不保证和用户前端的跳转时序一致。
如果代码里简单写一句 order.setStatus(PAID)，那么极有可能出现下面的竞态：用户点击取消订单，系统把订单状态改成了 CLOSED，这时候支付回调到达，又把状态强行改成 PAID。用户什么都没收到，钱却已经付出去了。
处理这个问题的核心思路是状态机加条件更新。
苍穹外卖的订单状态被我严格限制为几条合法路径：
- 待支付
PENDING_PAY可以进入已支付PAID，也可以进入已关闭CLOSED。 - 已支付
PAID可以被商家接单变成ACCEPTED。 - 配送完成后进入
COMPLETED。 - 只有部分状态可以进入退款流程。
支付回调处理逻辑不是直接赋值，而是执行一条条件更新 SQL：
sql复制UPDATE orders
SET status = 'PAID', pay_time = NOW(), pay_no = #{payNo}, version = version + 1
WHERE order_no = #{orderNo}
AND status = 'PENDING_PAY'
如果这条 SQL 影响的行数为 1，说明订单确实是从待支付状态被更新成已支付，这是一个合法的状态迁移。如果影响行数是 0，再查一次订单状态：如果已经是 PAID，直接返回成功的响应给第三方；如果是 CLOSED，说明订单之前被关闭了，这时需要进入“退款给用户”的补偿流程。
同时，每一次支付回调的原始报文都会落在独立表中，回调编号作为唯一键。第三方重复推送时，通过这个唯一键判断“这个通知我已经处理过了”，直接返回成功应答，避免重复入账。
这套设计并没有用到特别高深的技术，但它能解决真实资金链路里最吓人的问题。后来我把订单状态机整理成了一张 Excel 表，每次新接一个状态流转需求，第一件事就是看它有没有破坏原有迁移约束。
3.3 骑手抢单：Redis Lua 和数据库乐观锁怎么选
苍穹外卖里有个非常热闹的场景：平台同时把新订单推送给几十个骑手，谁先抢到谁接单。这里一定不能先查订单状态，判断是“待接单”再更新，因为查询和更新之间有时间差，两个骑手都可能读到“待接单”，最后都认为自己抢到了。
最简单可靠的办法是数据库乐观锁。在 dispatch 表里维护一个 status 字段，抢单时执行：
sql复制UPDATE dispatch_order
SET courier_id = #{courierId}, status = 'ACCEPTED', accept_time = NOW()
WHERE id = #{orderId}
AND status = 'PENDING'
只要影响行数大于 0，才表示抢单成功。这条 SQL 在数据库层面是原子操作，MySQL 会对满足条件的行加锁，另一个骑手的更新会阻塞或影响 0 行，天然不会出现一单多抢。
但如果某一天某个区域的热门订单抢单流量极高，数据库更新成为瓶颈，可以在 Redis 中缓存每个订单的分配状态，再用 Lua 脚本实现原子抢单：
lua复制local status = redis.call("GET", KEYS[1])
if status == "pending" then
redis.call("SET", KEYS[1], ARGV[1])
return 1
end
return 0
Lua 脚本能保证判断和写入两步操作在 Redis 中是原子的，不会出现两个骑手同时读到 pending 的情况。但使用 Redis 抢单成功之后，还需要通过消息队列异步把结果写入数据库，并处理 Redis 与数据库状态不一致的兜底。因此我建议，第一版还是优先选择数据库乐观锁，只有当单库单表确实扛不住抢单热点时，再引入 Redis Lua 方案。
4. 数据建模里容易返工的地方：商品、购物车与订单快照
4.1 菜品规格和 SKU 怎样建表才不别扭
外卖和普通电商一样，存在经典的规格问题。一道菜可能提供“大份/中份/小份”，不同份量价格不同；一份奶茶可能有“糖度”和“温度”两个维度，但价格又不一定变化。如果只在菜品表里放一个 price 字段，遇到规格价格不同的场景就做不下去了。
苍穹外卖里我把“店铺商品”和“可售卖的 SKU”分开建模。商品表保存名称、图片、分类、描述这类基础信息；SKU 表保存真正参与库存和价格计算的单位，例如“大份酸菜鱼”“中杯少冰珍珠奶茶”。每个 SKU 都属于某个商品，并单独维护价格和库存。
购物车和订单明细都只引用 SKU 维度，不直接引用商品维度。这样处理的好处是：用户加购大份酸菜鱼和加购小份酸菜鱼，后端能看到它们是两个不同的库存单位，后续结算、扣库存才能算得准。如果项目上线后商家需要增加“辣度”这种不影响价格的口味选项，我使用一个 JSON 字段记录了扩展属性，而没有强行将每个口味组合都扩展成 SKU，因为那样会让库存管理变得非常繁琐。
4.2 购物车为什么不能只存一个商品 ID
购物车是很多人觉得“太简单，一天写完”的表，但实际使用时却很容易翻车。如果购物车表只冗余 productId 和 quantity，进入结算页时就会出现两个问题：一是接口要频繁 join 商品表和 SKU 表才能展示当前价格；二是用户把商品加入购物车后，商家立刻改价，购物车里显示的数字和结算时实际扣款不一致，容易引发投诉。
我在设计购物车表时加入了 sku_id，并把前端展示需要的商品名称、图片和单价冗余到了购物车行里。每次加载购物车列表时，直接查购物车表就能拼出界面数据，速度快很多。同时，结算时我不会直接相信购物车表里的冗余价格，而是重新从最新的 SKU 表读取“当前真实价格”，再改变是否参与满减活动。购物车里的价格只服务于“看”，订单金额只相信“重新计算”的结果。
另外，购物车的幂等操作也很重要。用户快速点击两次“加入购物车”，不能被插入两行相同的数据。我使用 userId + sku_id 做唯一约束，存在相同记录时就执行数量加一，而不是重复插入。这个规则听起来简单，但漏掉它之后，我在测试环境经常看到同一个用户购物车里出现三条完全一样的记录。
4.3 订单里必须保留商品与地址快照
这是我认为苍穹外卖里最不该偷懒的一张设计。订单创建之后，商家有可能改名次、改价格、下架商品，甚至关闭店铺，用户历史订单里的菜名、价格、图片能不能保持原样，完全取决于订单里是否保存了快照。
我在订单主表里冗余了下单人昵称、手机号、收货地址这些字段，在订单明细表里保存了商品名称、SKU 描述、下单单价、数量、商品图片地址。用户查看历史订单时，后端直接读订单明细，不会再去 join 当前的菜品表。
如果订单只保存 product_id，一旦商家把“招牌黄焖鸡米饭”从 18 元改成 22 元，用户历史订单里也会跟着显示 22 元，财务对账、售后退款都会乱成一团。地址快照同理，用户修改或删除自己的默认地址后，历史订单里的配送地址必须保持不变，否则后续要查“三个月前的某个订单送到了哪里”，就彻底无从谈起。所以，凡是订单关联的业务数据，几乎都要在生成订单那一刻拷贝一份快照。宁可多占一点存储，也不能在业务回溯时丢数据。
5. 压测后我修复的真实问题：缓存、索引、延迟关单
5.1 菜单查询先别急着上 Redis，SQL 才是第一瓶颈
第一次给苍穹外卖做压力测试时，我发现首页菜品列表接口的 TPS 非常低。当时第一反应是“应该上 Redis 缓存”，但打开慢日志后发现，问题出在一条三层嵌套循环的查询里。每次返回店铺列表时，代码都会逐家店铺查询分类，再逐个分类查询菜品，典型的 N+1 问题。
我先把菜品列表查询改成了批量 SQL，使用 IN 查询一次加载某组店铺所有分类和商品，再在 Java 内存里做分组组装。这个改动没有引入任何缓存组件，接口响应速度就提升了三四倍。之后才是用 Redis 给热门的店铺菜品列表加缓存，过期时间设为 5 分钟。
在缓存策略上，我使用比较保守的 Cache Aside 模式：读请求先查缓存，缓存不存在再查数据库并回填；写请求更新数据库之后主动删除相关缓存，而不是先更新缓存。因为缓存是易失的，删除缓存后下一次读会从数据库重建，这样能大大降低缓存与数据库数据不一致的概率。等到项目体量进一步变大，再考虑用消息队列异步双删或者 Canal 订阅 binlog 来保证最终一致。
5.2 延迟订单关闭：定时轮询、Redis 过期监听、延迟队列
外卖订单如果一直不支付，会占住库存，也会影响商家备餐。系统必须在合理时间内自动关闭订单。实现方式有几种，我分别做了对比。
定时任务轮询是最简单的方式，每 30 秒执行一次 SQL，把所有超过 15 分钟仍未支付的订单批量置为关闭，并回补库存。缺点是存在一定的延迟，而且大批量扫描会影响数据库性能。Redis 过期监听也可以实现，但 Redis 的 key 过期通知并不保证消息即时到达，如果 key 大量堆积还可能影响效率，线上我不敢只依赖它。
最后我选用 RabbitMQ 延迟队列实现。下单时向延迟队列发送一条消息，消息带上 orderNo，并设置 TTL 为 15 分钟。消息过期后会自动进入死信队列，由消费者查询订单状态，如果订单还是待支付，就执行关闭并释放库存。为了避免极端情况下消息丢失，我会另外用 XXL-Job 每隔 5 分钟扫一次“支付超时但状态尚未关闭”的订单做兜底。
这套组合在实际运行中表现稳定。订单能基本按约定时间关闭，同时不会因为扫描订单表太频繁而拖垮主流程。
5.3 压测暴露出来的三个典型问题
我用 JMeter 模拟了三个典型的压力场景：商品秒抢、提交订单、骑手刷新抢单列表。压测过程中暴露的问题，比项目顺利运行时学到的还多。
| 压测场景 | 现象 | 根因 | 修复方式 |
|---|---|---|---|
| 高并发抢购商品 | 库存扣成负数 | 扣减库存 SQL 只判断了库存大于 0，却写成了先查询再更新 | 改为一条 UPDATE：UPDATE sku SET stock = stock - #{n} WHERE id = #{id} AND stock >= #{n} |
| 高频提交订单 | 数据库连接池耗尽 | 有个接口在循环中单条查询，占据了大量连接 | 批量查询代替循环查询，同时打开慢 SQL 日志 |
| 大量请求访问不存在菜品 | 数据库压力飙升 | 用户请求恶意带不存在的 ID，每次缓存都未命中 | 参数校验以及空值短时间缓存，防止缓存穿透 |
这些问题没有一个是偏门难题，全部来自最常见的编码习惯。项目只有真正跑在压测工具下，才会暴露出“查一次没事，查一万次就会出事”的真相。
5.4 观测手段比压测工具本身更重要
压测时不能只盯 TPS 和平均响应时间，我还会同时开启以下几类观测：MySQL 慢日志、Redis 命中率、JVM GC 日志、RabbitMQ 堆积数量。如果接口变慢，先在链路里找到到底慢在哪一层，而不是盲目加机器。
用 Arthas 查看线上接口的调用耗时是一个高效手段，它能看出某个方法到底执行了几次 SQL、每次 SQL 耗时多少。我排查过一次下单慢的问题：订单方法里居然调用了三次查询用户地址的接口，而用户地址数据根本没变化，于是把查询结果放到方法内变量直接复用，下单耗时立刻降了下来。
这类性能问题，单纯看代码很难发现，只有结合压测中真实的调用日志，才能快速锁定瓶颈。
6. 把苍穹外卖当成产品运营，才会留下真正值钱的经验
6.1 售后与异常订单状态，不能只停留在“已完成”
外卖订单做完就算结束了吗？不是的。用户可能因为没有收到餐、餐品洒漏、商家漏发货等原因申请售后。苍穹外卖在设计状态机时，我加入了 REFUNDING、REFUNDED、COMPLAINT 等状态。退款流程和支付流程一样，必须保证幂等。用户多次点击“申请退款”，后端只能创建一条退款申请单；退款回调到达后，也要防止给同一个订单重复打款。
售后单和原始订单之间是一对多的关系。一个订单可能先申请整单退款，之后又只对部分商品申请退款，所以我没有把退款状态塞进订单表，而是拆了独立的售后表，通过 order_no 关联。这样做的好处是，财务和客服查询时能清楚看到每笔退款对应的商品和金额。
6.2 优惠券和积分，会让系统瞬间增加一层复杂度
苍穹外卖做到二期后，我加入了优惠券功能。本以为只是“用户下单前选一张券，支付时减掉对应金额”，结果一实施才发现它牵扯到券模板、库存、用户领券记录、使用校验、过期处理等多个环节。
优惠券发放要防止超发，我使用 Redis 的原子自增记录已发放数量，超过模板总量就拒绝领取。下单使用优惠券时，又要防止并发下单重复消耗同一张券，我把优惠券的“已使用状态更新”也做成了条件更新：
sql复制UPDATE coupon_user
SET status = 'USED', order_no = #{orderNo}
WHERE id = #{couponId}
AND status = 'UNUSED'
影响行数为 1 时，才允许这笔订单享受优惠。这个套路和骑手抢单本质上是一样的：先到先得，状态保证原子迁移。如果一开始没有把优惠券状态设计和订单状态对齐，很容易出现“一张券被两笔订单同时用了”的事故。
6.3 商家审核与操作日志，能撑起平台的信任基础
苍穹外卖如果继续向平台化发展，还需要加入商家入驻审核、资质材料上传、定期巡检等后台功能。我在设计商家表时预留了 status 字段：待审核、营业中、暂停营业、已关闭。商家提交的营业执照、门头照片、食品经营许可证等材料放到了对象存储中，后台审核员可以查看完整资料后作出决定。
所有比较敏感的后台操作都需要记录操作日志，我自己用 AOP 注解实现了统一切面，记录操作人、操作时间、目标对象、操作前值、操作后值和 IP 来源。例如商家管理员把菜品下架、修改运费、驳回退款，这些操作都必须能回溯。没有日志的后台就像没有监控的航班，出了事故根本不知道从哪个环节开始查。
如果现在让我给后来的同学一句建议，我会说：把苍穹外卖当成一个永远做不完、但是必须能跑完的产品去看待，比把它当成毕业设计去看，收获会多得多。这个项目里真正值钱的地方，不在于它用了多少新技术，而在于你是否想通了为什么“用户、库存、优惠券、订单状态”都要做并发控制，为什么支付回调需要幂等日志，为什么历史订单要保存快照。这些细节一旦想明白，以后再换一个点餐系统、换一个预约系统、换一个票务系统，你的思考方式都会比只写过一遍 CRUD 的人扎实很多。苍穹外卖也许不会让你的简历瞬间闪光，但它有机会成为你第一份真正理解业务闭环的经验。