苍穹外卖项目实战：Spring Boot业务系统与部署优化全解

1. 项目概述：苍穹外卖到底在做一件什么事

提到“苍穹外卖”，很多人第一反应是“这又是一个外卖平台练习项目”。但实际上，这个项目远远不止“一个简单的外卖系统”这么简单。从用户打开微信小程序浏览菜品，到商家在管理后台接单，再到骑手完成配送，最后到店铺后台生成营业数据报表，这是一条非常完整、链条很长的业务闭环。它几乎把一个真实外卖平台涉及的典型业务模块都覆盖了：商品展示、购物车、下单、支付、接单、配送、订单状态流转、营业统计、定时任务、消息推送等等。

我当时选择做这个项目，是因为它有一个其他练习项目很难替代的特点：业务复杂度刚好卡在一个“不上不下”的位置。再简单一点，比如只做一个商品CRUD，学了跟没学一样，根本接触不到缓存、消息推送、定时任务这些现实业务里绕不开的东西。再复杂一点，比如直接上微服务全套（Nacos、Gateway、Sentinel这些），新手很容易被分布式环境淹没，最后自己写的东西跑不起来，也不知道问题出在哪。苍穹外卖这种“单体架构 + 模块化设计”的方式，恰好适合大多数人把手写进代码里，把一个业务从数据库设计一路做到功能上线。

这个项目适合三类人：第一类是Java后端初学者，学完SSM或Spring Boot基础语法后，需要找一个完整项目来串知识点；第二类是准备找工作的朋友，手里需要一套“能讲清楚业务、能经得起深挖”的项目经验；第三类是打算做毕业设计、课程设计的学生，它比单纯的管理系统有价值得多，而且可以往微服务方向继续扩展。

这篇文章里，我会从整体设计思路、核心模块的细节实现、实操过程、常见问题排查这四块来拆解，把我自己实际做的时候踩过的坑和优化过的方案都写出来，分享给打算做或者正在做类似项目的朋友。

2. 整体设计与技术选型：这套方案为什么要这样做

2.1 需求拆解：外卖平台的核心用户和核心场景

做任何项目之前，先把“谁在用、用来干什么”想明白，比一上来就写代码重要得多。苍穹外卖涉及的核心使用者分四类：用户（消费者）、商家（店铺管理员）、平台管理员、骑手。如果把四个角色的功能堆在一个系统里，代码会非常臃肿，权限也不好控制。所以这个项目从一开始就定义了清晰的边界：用户端是微信小程序，商家端和管理端是Web管理后台，骑手端则可以借助商家端/管理端的接单模块来完成配送流程。

用户端核心场景：注册登录、浏览店铺和菜品、把菜品加入购物车、提交订单、支付、查看订单状态、催单或者取消订单。

商家端核心场景：店铺管理、菜品分类管理、菜品增删改查、套餐管理、订单接单/拒单、订单派送、营业数据查看。

管理端核心场景：分类管理、菜品管理（和商家端类似但视角不同）、套餐管理、员工账号管理、数据统计报表。

搞清楚场景之后，后端接口的设计就能按角色划分出清晰的模块，而不是所有功能堆在一个Controller里。比如用户端的接口统一走 /user/** 前缀，管理的接口走 /admin/** 前缀，这样后面做拦截器权限控制的时候就非常方便，只要对不同的URL前缀配置不同的规则即可。

2.2 技术栈落位：为什么是Spring Boot + Vue + Redis + Docker这套组合

苍穹外卖主流的实现方式是前后端分离：后端用Spring Boot，前端管理后台用Vue（Element UI），用户端是微信小程序。这个技术选型很现实，因为绝大多数公司现在就是这个组合，学完之后能直接用在生产项目上，简历上的匹配度也高。

核心组件选型如下：

有一点要注意，这个项目不是“技术越多越好”的堆砌，而是每一项技术都有明确的业务场景。比如Redis如果只用来存一个验证码，那完全没必要引入，但在这个项目里，Redis还要扛菜品缓存和购物车数据，那引入就顺理成章。面试时被问到“为什么用Redis”，你不能说因为大家都在用，而要说清楚：菜品的访问频率远高于修改频率，加缓存可以把顶住高频读取；购物车数据适合用Redis的Hash结构存储，每个用户一个key，field是菜品id，value是数量，天然匹配业务模型。这一套逻辑说得通，技术选型就站得住。

2.3 模块边界划分：单体架构下的职责清晰

苍穹外卖虽然是单体应用，但代码结构必须是“单体骨架、模块化思想”。我建议把代码按业务域分包，而不是按技术层分包。

按业务域分包的意思是把 controller、service、mapper 这层技术概念按“业务模块”拆分：user、admin、common 这种顶层包，下面各自放自己的controller、service、mapper。按技术层分包则是凭空分出 controller 包、service 包、mapper 包，再在包下面塞一大堆类。项目小的时候看不出来差距，但业务一多，按技术层分包会乱得很难查：你找一个订单相关的Controller，要在好几百个类里翻。我后来做重构的时候体会非常深，按业务域分包之后，定位一个功能基本上1分钟以内就能找到入口。

bash复制sky-food
├── sky-common          # 通用模块：常量、异常、工具类、枚举
├── sky-pojo            # 实体类：Entity、DTO、VO
├── sky-server         # 主服务：Controller、Service、Mapper、配置
└── sky-web            # 前端管理后台（Vue）和用户端小程序（单独仓库）

后端主服务内部再按业务模块拆包：

bash复制com.sky
├── controller
│   ├── admin          # 管理端接口
│   └── user           # 用户端接口
├── service
├── mapper
├── config             # 配置类（WebMvc、Redis、OSS、WebSocket等）
├── interceptor        # JWT拦截器
├── handler            # 全局异常处理器、MyBatis公共字段填充
├── task               # 定时任务
└── websocket

这个结构看起来简单，但它保证了两件事：一是管理端接口和用户端接口天然隔离，拦截器可以用前缀规则做权限控制；二是每个同学在fork项目之后，不会因为包结构混乱而找不到入口，学习成本低。

3. 核心细节解析与实操要点：这些功能不能只做表面功夫

3.1 用户登录与鉴权：JWT + ThreadLocal的上下文传递设计

苍穹外卖的用户端登录走的是微信小程序登录：前端调用微信提供的 wx.login() 获取临时code，后端拿这个code去微信服务器换openid（用户唯一标识），然后生成JWT token返回给前端。管理端登录则是普通账号密码登录，校验通过后生成JWT。

JWT鉴权这里有一个细节很值得说——ThreadLocal传递用户ID。拦截器在请求进来时解析出JWT中的userId，存进ThreadLocal；请求处理完成后，在拦截器的afterCompletion方法里必须清除ThreadLocal。为什么必须清除？因为Tomcat的工作线程是复用的，如果不清理，下一个请求如果没走拦截器（比如某个白名单接口），可能会读到上一个线程残留的用户信息，这在低并发下可能好几天都不出现，一旦有并发就出诡异Bug，而且非常难查。

ThreadLocal的用法很简单：

java复制public class BaseContext {

    private static ThreadLocal<Long> threadLocal = new ThreadLocal<>();

    public static void setCurrentId(Long id) {
        threadLocal.set(id);
    }

    public static Long getCurrentId() {
        return threadLocal.get();
    }

    public static void removeCurrentId() {
        threadLocal.remove();
    }
}

比如用户端购物车模块，后端需要知道“当前是哪个用户在加购物车”，这时候直接从BaseContext里拿userId就行，不用把userId放到每个请求的DTO里传来传去，代码干净得多。

关于JWT还有一个容易踩的坑：secret密钥和过期时间不能写在代码里。密钥要放到配置文件里，用环境变量注入，过期时间不要设置太长也不要太短。管理端建议设置2小时，用户端小程序可以设置7天，因为用户不会频繁重新登录，但出于安全考虑也不能太长。如果设置成永久有效，token泄露了就没法吊销，这是一件很恐怖的事情。

3.2 缓存设计：菜品、分类、购物车的Redis存储细节

这个项目中Redis有三处核心应用，每一处的设计和注意事项都不同。

第一处是菜品缓存。用户端小程序查看菜品是不需要登录的，浏览频率很高。如果每次都查数据库，高峰期一个菜品接口的QPS可能打到几千，MySQL扛不住。我用的是Redis String结构，key的规则是 dish:categoryId:xxx，value是菜品类目下所有菜品组成的JSON数组。用户端查询菜品时先查缓存，缓存没命中再查数据库并写入缓存。商家端修改菜品后，需要删除对应分类下的缓存，保证下次查询拉到最新数据。

这里有一个非常关键的坑：修改菜品时要同时考虑这个菜品是否属于某个套餐。如果一个菜品被套餐引用了，你只删了菜品缓存不删套餐缓存，用户端看到的套餐还是修改前的数据。我在实际开发中第一次就漏了这一点，测试的时候单点菜品没问题，一点套餐就发现价格还是旧的。后面总结出来的规则是：凡是涉及菜品改动的操作，除了删除菜品缓存，还必须把包含这个菜品的所有套餐缓存一并清除。

第二处是购物车缓存。购物车数据的特点是“频繁读写、数据量大、不需要强一致”。我用了Redis的Hash结构存储，key是 cart:userId，field是菜品id，value是选中的菜品数量。商家端要改价格、要批量修改菜品状态的时候，购物车里存这种冗余数据就会出现新问题：用户加购物车时存了价格A，后来商家改成了价格B，用户结算时按哪个价格算？正确的做法是购物车里存商品快照（名称、图片、单价），下单时再实时查一遍数据库中的最新价格进行二次校验，如果价格变了要给出提示。这个细节面试经常问，实际操作也很容易踩坑。

第三处是验证码存储。管理端登录有验证码，验证码是敏感数据，必须设置过期时间。我用的方案是Redis String存储，key是唯一UUID，value是验证码内容，并设置5分钟有效期。校验时先查缓存再比对，比对成功立即删除（一次性使用），防止暴力重放。

3.3 订单状态机与超时处理：Spring Task实现自动取消

外卖订单的完整状态流转是这样的：

code复制待付款(1) -> 待接单(2) -> 待派送(3) -> 派送中(4) -> 已完成(5)

其中还有两个特殊状态：已取消(6)，已退款(7)。

待付款订单一段时间内没支付，必须自动取消。苍穹外卖里的实现是用Spring Task做定时任务，每隔1分钟扫描一次数据库，把创建时间超过15分钟且状态为待付款的订单改成已取消，同时把库存加回去。

Spring Task用法很简单，在配置类上加上 @EnableScheduling，任务方法上加 @Scheduled(cron = "0 0/1 * * * ?")，方法内部写业务逻辑即可。但有几个细节要注意：

第一个细节是扫描需要考虑数据库的延迟。比如当前时间是12:00:00，有个订单是11:45:59创建的，如果按“创建时间 < 当前时间 - 15分钟”这样粗暴比较，这个59秒前创建的订单正好差1秒没到15分钟，下一轮扫描是12:01:00，延迟也就1秒，完全可以接受。但如果任务本身执行太久，比如扫了2分钟，那扫描出的结果就可能包含一些“刚刚好满15分钟”的订单，业务上没问题，只是状态变化会比预期晚几十秒。

第二个细节是取消订单之后要回滚库存。如果商家已经接单了，用户不能直接取消，只能走申请退款流程。这个逻辑在订单状态判断里要非常严格，不能只判断状态码，还要判断操作人的角色权限。

第三个细节是定时任务的幂等性。单体项目只有一个应用实例还好，如果以后部署了多个实例，同一个定时任务就会在每台机器上各执行一次。解决思路是使用Redis分布式锁：先尝试获取锁，拿到锁的实例才执行任务，执行完释放锁，这样保证同一时间只有一个实例扫描处理。这个思路在面试时主动讲出来，会是一个很大的加分项。

3.4 来单提醒：WebSocket连接管理与推送时机

用户在小程序下单成功之后，商家端/管理后台要立刻收到一个“新订单”提醒，如果靠商家自己刷新页面，体验会很差，而且响应不及时。苍穹外卖这里用的是WebSocket。后端有一个WebSocket端点，商家端/管理端连接后，每次有人下单就推送一条消息，前端收到后弹出提示音和弹窗。

实现细节上，最核心的是理解WebSocket的session管理。后端要用一个线程安全的Map或Set保存所有在线的连接session，key可以是商家/管理端的用户id，value是Session对象。这样后端才能做到“给指定的人推送”。如果只用普通的list存session，根本不知道这个连接属于谁，推送就只能群发，这在生产环境是不可接受的。

java复制@Component
@ServerEndpoint("/ws/order")
public class OrderWebSocketServer {

    private static Map<Long, Session> sessionMap = new ConcurrentHashMap<>();

    @OnOpen
    public void onOpen(Session session) {
        Long userId = (Long) session.getUserProperties().get("userId");
        sessionMap.put(userId, session);
    }

    @OnClose
    public void onClose(Session session) {
        Long userId = (Long) session.getUserProperties().get("userId");
        sessionMap.remove(userId);
    }

    public void sendToUser(Long userId, String message) {
        Session session = sessionMap.get(userId);
        if (session != null && session.isOpen()) {
            session.getBasicRemote().sendText(message);
        }
    }
}

这里有两个常见的坑。第一个坑是@ServerEndpoint的类实例和Spring容器不互通，也就是说在WebSocket类里不能用@Autowired直接注入Service。解决办法是加一个静态字段，通过Spring上下文工具类手动获取Service bean。第二个坑是连接鉴权。WebSocket建立连接的握手阶段要在拦截器中解析token，先鉴权再建立连接。如果不鉴权，任何人知道WebSocket地址就能连接上来，轻则打日志刷屏，重则订单信息泄露，属于很严重的安全漏洞。

3.5 营业数据统计：如何聚合订单和菜品数据

管理端的“数据统计”模块包括营业额统计、用户统计、订单统计、销量排名Top10。这个模块听起来简单，好像就是从订单表按日期分组汇总，但真的要统计准确，有几个细节处理不好就是错的。

营业额统计需要区分“已完成的订单”和“已取消的订单”，不能把所有状态的订单金额都算进去。而且支付金额和订单金额可能因为退款、优惠券等原因不一致，统计口径要明确：建议以支付流水表的实付金额为准。

销量排名Top10有一个很典型的坑：外卖订单是一单多品的，订单表只存了总金额，没有存每个菜品的数量。你需要单独的表记录每个订单包含了哪些菜品、每份多少。苍穹外卖里有 order_detail 表，每一行就是一个订单里的一个菜品。统计时按菜品id分组求和，按数量倒序排，取出前10条。如果不先建好表结构，后期再加这种统计报表，就要改表结构、改下单逻辑，成本非常高。所以建表这一块，大家不要偷懒简化，该有的关联表一定要有。

4. 实操过程与核心环节实现：从零跑通一个完整的业务闭环

4.1 环境准备与项目初始化：先把地基打稳

在实际动手之前，先把环境准备好。我的建议是这样的：

• JDK版本用8或11，不要一上来就用17，很多老项目依赖的库还没有完全适配，徒增烦恼。
• MySQL用5.7或8.0，字符集设置为utf8mb4，排序规则选utf8mb4_general_ci或strict都可以，但必须统一，否则关联查询时可能会出现排序规则冲突报错。
• Redis用5.x以上版本，不需要太多额外配置，默认端口就行。
• Node.js用来跑前端管理后台，建议v14以上，但不要追最新版，前端依赖有时候会跟最新的Node版本有不兼容的情况。
• Docker用于部署，如果你本机资源够，可以直接用Docker Compose把MySQL、Redis一起编排起来，后面清理重来很方便。

我用Docker Compose把基础环境跑起来的：

yaml复制version: "3"
services:
  mysql:
    image: mysql:5.7
    container_name: sky-mysql
    environment:
      MYSQL_ROOT_PASSWORD: root123
      MYSQL_DATABASE: sky_take_out
    ports:
      - "3306:3306"
    volumes:
      - ./mysql-data:/var/lib/mysql
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_general_ci

  redis:
    image: redis:6
    container_name: sky-redis
    ports:
      - "6379:6379"

第一次启动后，先确认MySQL和Redis都连得通，再开始导入项目里的 sky.sql 数据库脚本。这一步我会做一次数据脚本的完整执行，然后查几个核心表的数据量，确认表都建出来了。比如 employee 表应该有初始管理员账号，category 表应该有几个菜品分类的数据。

4.2 数据库核心表结构：这几个表的设计决定了后端的开发难度

苍穹外卖的数据库表有个很经典的集合，我挑几个核心表重点说明。

employee表（员工/管理员账号）：字段有id、name、username、password、phone、status、create_time、update_time等。password是MD5加密存储，第一次登录建议强制改密。

category表（菜品/套餐分类）：字段有type（1菜品分类、2套餐分类）、name、sort、status、create_time、update_time。这个表的type字段是业务分流的关键，菜品管理里展示的分类只查type=1的数据，套餐管理展示的分类查type=2的数据。

dish表（菜品）：字段有name、category_id、price、image、description、status、create_time、update_time、create_user、update_user。注意这里的create_user和update_user是通过MyBatis的公共字段自动填充的，不需要在业务代码里手动set。

setmeal表（套餐）和setmeal_dish表（套餐和菜品的关联表）：套餐是菜品的组合。setmeal_dish表必须存在，因为套餐详情页面需要列出这个套餐包含了哪些菜品，一份多少钱。

shopping_cart表（购物车）：字段有user_id、dish_id、setmeal_id、name、image、number、amount、create_time。一个用户一条记录对应一个菜品/套餐和数量。设计时要注意加一个唯一索引 (user_id, dish_id) 或者 (user_id, setmeal_id)，避免重复数据。

orders表（订单主表）：字段有number、user_id、address_book_id、order_time、checkout_time、pay_method、amount、remark、status、username、phone、address、consignee。订单表存储的是用户的收货信息快照，不是关联用户表去查，因为用户修改收货地址后，历史订单的收货信息不能跟着变。

order_detail表（订单明细表）：字段有order_id、dish_id、setmeal_id、name、image、number、amount。一个订单在orders表一条记录，在order_detail表对应多条记录。

address_book表（用户地址簿）：字段有user_id、consignee、phone、sex、province、city、district、detail、label、is_default。用户的收货地址可以有多个，只有一个默认地址。

建表之后，最影响后期开发效率的是索引。orders表要按user_id和status组合查询，order_detail表要按order_id查询，这两张表数据量随着业务增长是膨胀最快的，索引一定要在建表时就建好。

4.3 用户端下单链路走通：从加购物车到订单支付

用户端下单的完整链路我建议先走一遍，把前后端接口都调通，再继续做其它模块。这条链路的关键接口有：

第一步，用户登录。前端 wx.login() 获取code，后端调用微信接口换取openid，首次登录自动注册，然后生成JWT返回。

第二步，浏览菜品。前端请求分类列表和菜品列表，后端先查Redis缓存，命中的话直接返回JSON，不命中的话查数据库并写回缓存。这里要确保返回的VO结构里包含菜品图片的完整URL，/imgs/xxx.jpg 这种相对路径在跨端场景下会显示不出来。

第三步，加入购物车。前端传菜品id、口味信息，后端从BaseContext里拿到userId，判断Redis里有没有这个用户、这个菜品的记录。如果有，number加1；如果没有，新建记录并设置number为1。这里有一个业务细节：同一菜品不同口味要区分，你不能把“微辣”和“特辣”的同一个菜合并成一份。菜品的规格在dish_flavor表里配置，前端把选好的口味拼接成一个字符串存到购物车记录的dish_flavor字段里。

第四步，提交订单。前端提交收货地址id、备注、预计送达时间等，后端要做几件事：

• 根据用户id查出购物车所有记录
• 根据最近地址簿数据组装订单信息
• 循环计算总金额，这里用BigDecimal，不要用double
• 插入orders表，状态为待付款(1)
• 批量插入order_detail表
• 清空用户的购物车
• 将订单写入Redis用于超时检测，或直接依赖定时任务扫描数据库

第五步，支付。真正的生产环境接入微信支付流程比较长（需要商户号、API证书、回调地址等），本地开发可以用模拟支付：用户在管理端/小程序端点击“模拟支付”，后端直接把订单状态改为待接单(2)，并把订单号推送到商家端WebSocket。这样做的好处是业务闭环能跑通，不依赖真实支付环境，缺点是要记得支付回调里有一堆签名校验逻辑，真实上线时再补上。

第六步，来单提醒。用户支付成功后，后端调用 orderWebSocketServer.sendToUser(商家用户id, "您有新的订单...")，商家端页面收到消息后弹出提示并播报语音。

4.4 商家端接单与派送流程：状态推动词要非常清晰

商家端在管理后台看到新订单后，可以接单，也可以拒单。接单就是把订单状态从待接单(2)改成待派送(3)；拒单需要填写原因，这个订单会进入退款流程。

这里有一个很重要的权限细节：不同角色能操作的状态不一样。管理员可以查看所有订单，商家只能看到自己店铺的订单。苍穹外卖中的商家业务表和管理员表如果分开了，就要在订单查询SQL里加上店铺条件；如果合并成同一张employee表，就要用字段区分角色类型。

派送流程在真实外卖平台里是独立的骑手端操作，但苍穹外卖简化了：商家接单后可以点击“派送”，订单状态从待派送(3)变成派送中(4)，然后点击“完成”，订单状态变成已完成(5)。如果你是扩展这个项目，可以考虑增加一个骑手角色，用手机号+验证码登录，接单后锁定订单，配送完成后再改成已完成，业务流程会更真实。

4.5 管理端数据统计报表：一套报表接口背后的SQL

管理端统计模块我建议做成按日期查询的接口，前端用ECharts展示折线图和柱状图。后端接口设计：

• GET /admin/statistics/turnover?begin=xxx&end=xxx —— 营业额统计
• GET /admin/statistics/orders?begin=xxx&end=xxx —— 订单统计
• GET /admin/statistics/salesRanking?begin=xxx&end=xxx —— 销量排名Top10

营业额统计SQL的核心思路：

sql复制SELECT DATE_FORMAT(order_time, '%Y-%m-%d') AS day, SUM(amount) AS turnover
FROM orders
WHERE status = 5
  AND order_time BETWEEN #{begin} AND #{end}
GROUP BY day
ORDER BY day;

销量排名Top10的SQL：

sql复制SELECT d.name, SUM(od.number) AS sales
FROM order_detail od
LEFT JOIN dish d ON od.dish_id = d.id
LEFT JOIN orders o ON od.order_id = o.id
WHERE o.status = 5
  AND o.order_time BETWEEN #{begin} AND #{end}
GROUP BY od.dish_id
ORDER BY sales DESC
LIMIT 10;

这个SQL里有一个容易忽略的细节：为什么订单要限定status=5？因为只有已完成的订单才计入有效销量，已取消、已退款的订单不能算。如果不加这个条件，统计出来的数字会偏高，看起来销量很好，但实际上很多是无效订单。

5. 常见问题与排查技巧实录：我把踩过的坑都整理出来了

5.1 金额精度问题：double浮点带来的脏数据

这是外卖订单系统里最容易出问题的地方，没有之一。用double计算金额，比如0.1 + 0.2，结果不是0.3，而是0.30000000000000004。如果订单金额计算发生在后端，存到数据库时就可能带上一堆奇怪的小数位，对账的时候会发现账对不上。

我的规则是所有涉及金额的字段都用 BigDecimal，构造方法只接受String类型，不要用 new BigDecimal(0.1) 这种写法，要用 new BigDecimal("0.1")。计算时用 add、subtract、multiply、divide 方法，除法要指定小数位和舍入模式，比如 divide(quantity, 2, RoundingMode.HALF_UP)。

数据库里金额字段用 DECIMAL(10, 2)，这个类型在MySQL里是定点数，不会出现浮点误差。实体类里对应字段也必须是BigDecimal，不要用Double去接收。

5.2 缓存一致性：菜品改了，前端还是老数据

这个问题在联调时最容易发现：商家在后台把菜品价格从30改成25，用户端小程序刷新后还是显示30。原因就是用户端读取的是Redis缓存，而商家端修改后没有清缓存。

排查思路分三步：

1. 确认修改操作里是否主动删了缓存。检查Service层，在updateDish业务里调用了 redisTemplate.delete("dish:categoryId:" + categoryId) 没有。
2. 确认删除的key和查询的key是否一致。比如查询时用的key是 dish:categoryId:1，删除时如果拼错写成了 dish:categoryId:2，那第2个分类的缓存永远清不掉。
3. 确认是否只删了菜品缓存而没删套餐缓存，这个前面也提过。

如果在并发量高的时候，还有一种更麻烦的情况：先删缓存、后更新数据库，在更新数据库的间隙，另一个线程查到旧数据写入缓存，导致缓存永远是新旧交替的脏数据。处理方案有两种：一种是延迟双删，先删缓存、更新数据库、休眠几百毫秒再删一次缓存；另一种是更新数据库后通过消息队列异步删缓存。对于苍穹外卖的并发量，用延迟双删基本够用，实现也不复杂。

5.3 定时任务不执行：Spring Task的踩坑记录

有一次我配置的定时任务一直不执行，纠结了很久，后面才发现是Scheduled注解的cron表达式写错了。Spring的cron表达式有6位，格式是 秒 分 时 日 月 周，跟Linux的cron表达式（5位）不一样。如果照搬Linux的习惯写成 0 * * * * ?，会直接报错。这里一定要记住最后一位用 ?（不指定）或者 *，但不能同时指定日和周。

还有个坑是定时任务方法抛异常后，后续任务不再执行。Spring Task默认会捕获异常打印日志，但不会影响下一次调度。如果日志配置不对，抛异常只会输出到控制台，不落文件，给排查带来了很大的麻烦。我的习惯是：定时任务方法内部自己try-catch，把异常打全，并且做好状态记录，不要在方法外面裸奔。

再深入一点，如果任务执行时间超过调度周期，Spring Task默认上一轮没执行完下一轮不会开始，但任务本身可能堆积。比如任务执行了3分钟，调度周期是1分钟，那任务实际上变成3分钟一个周期。如果业务上不能忍这种阻塞，就要考虑用独立的线程池Executor来跑任务，或者改成分布式调度框架（如XXL-Job）。对于苍穹外卖这种轻量项目，Spring Task已经够了，面试时把优缺点讲清楚比硬上框架更让人信服。

5.4 WebSocket连接不稳定：推送消息收不到

WebSocket最烦的问题就是“连上了但消息收不到”或者“消息发出去对方没反应”。我遇到过的原因有几种：

第一种是Session失效。用户连接后长时间不操作，服务端可能已经断开了这个session，但sessionMap里还留着旧对象，推送时调用 sendText 就会抛异常。解决方法是推送前判断 session.isOpen()，如果是false就先移除再跳过，或者尝试重连。

第二种是连接未鉴权。如果你在HandlerInterceptor里校验了token，但WebSocket握手不走这个拦截器，那就等于裸奔。解决方法是扩展Spring的 HandshakeInterceptor，在beforeHandshake方法里从query参数或header里拿token，校验通过才返回true。

第三种是前端没处理重连。小程序端或者浏览器端的WebSocket断开后不会自动重连，需要在前端代码里写心跳和重连逻辑。心跳就是每隔30秒前端发一个ping，后端回一个pong，如果连续几次没收到pong就主动断线重连。这个做法虽然简单，但能极大改善体验。

5.5 图片上传失败：OSS配置经常出问题的几个点

苍穹外卖里的菜品图片上传是典型场景。我在实际项目中用过本地存储，也用过OSS，总结一下：生产环境一定要用对象存储，不要存在本地服务器，不然服务器磁盘早晚被图片塞满，而且用户端图片访问也变慢。

OSS配置容易出问题的点：

• Endpoint、AccessKeyId、AccessKeySecret这些配置要准确，尤其是Endpoint不要带 https:// 前缀，只用 bucket.region.aliyuncs.com 这种域名。
• 上传时 key 路径设计要规范，比如 yyyy/MM/dd/uuid.jpg，不要直接拿用户传入的文件名做路径，防止路径穿越。
• 返回给前端的URL要用可公开读取的bucket外网域名，如果bucket是私有读写的，URL会带签名参数，需要额外拼接。
• 文件大小限制：Spring Boot默认上传文件不能超过1MB，如果菜品图片大一些就报异常。需要在配置文件中调大，通常是：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 10MB

还有一个坑是修改文件后是否真的替换了OSS上的旧文件。如果在Service里只是把数据库的图片地址改了，而旧文件没有删除，OSS里的存储量会越来越大。删除文件需要调OSS的delete接口，但要注意不能删除默认图片或者公共占位图，不然会导致页面图片全部失效。

5.6 搭建项目时常见的5个问题和解决建议

我在带朋友跑这个项目的过程中，发现有几个问题出现频率特别高，这里汇总成一个速查表，方便大家对号入座。

这些问题里，最值得展开说一下的是数据库中文乱码。它通常在导入SQL脚本后执行查询时发现，名字字段全是问号。原因是创建数据库时没指定字符集，或者连接串没指定编码。建议建库SQL写成：

sql复制CREATE DATABASE sky_take_out DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

MySQL 5.7和8.0对utf8mb4的支持都很好，不要用utf8，因为utf8在MySQL里实际是utf8mb3，存不了emoji和部分生僻字。一个小细节，但这个细节你做项目的时候不处理好，后面所有带中文的接口都可能出幺蛾子。

6. 实测下来的一些优化思路与部署实践

6.1 多环境配置管理：开发环境和生产环境要分开

很多人在本地把配置改好了，部署上线时又手忙脚乱，改完数据库连接忘了改Redis地址，改完OSS配置忘了改日志路径。我建议从一开始就做多环境配置，Spring Boot里对应多个profile文件：

yaml复制spring:
  profiles:
    active: dev

• application-dev.yml：本地开发环境，数据库localhost，Redis localhost，日志输出到控制台。
• application-prod.yml：生产环境，数据库、Redis、OSS都走环境变量注入，日志写到文件并按天滚动。

这样部署时只需要设置 SPRING_PROFILES_ACTIVE=prod，剩下的配置全部由环境变量提供，不把敏感信息写死在代码里。这一套在面试中也是一个不错的加分项，能够体现出你对环境治理的思考。

6.2 Docker Compose一键部署：把前后端跑起来

我自己在项目收尾时是用Docker Compose做的部署，把后端jar包、前端静态资源、MySQL、Redis一起编排。这个步骤建议大家在本地也演练一遍，因为它能把“本地能跑”和“生产能跑”之间的差距补上。

前端管理后台打包后生成dist目录，里面是纯静态文件，用Nginx托管。我会把dist目录挂载到Nginx容器里，同时配置Nginx把 /api 开头的请求反向代理到后端服务。

nginx复制server {
    listen 80;
    server_name localhost;

    root /usr/share/nginx/html;
    index index.html;

    location /api/ {
        proxy_pass http://sky-server:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Docker Compose编排的时候，backend服务用 http://sky-server:8080/ 来访问MySQL和Redis，这是Docker内部的服务名解析，不是localhost，比在宿主机配置IP要稳定得多。第一次跑的时候经常有人把这里配成localhost，容器内访问不到宿主机，就会一直报connection refused。

6.3 从单体到微服务的扩展方向

如果你学完苍穹外卖还想往高处走一步，可以把项目按业务拆成微服务架构。常见拆法是把用户端、商家端、管理端拆成独立服务，或者按业务域拆成订单服务、商品服务、支付服务。拆完之后要引入注册中心Nacos、网关Gateway、配置中心、分布式事务（比如Seata）这些组件，工作量和复杂程度会上一个台阶。

但这里我要提一个很多人都会犯的毛病：在单体都没跑明白的时候，盲目引入微服务是灾难。微服务不是银弹，你拆出来的每个服务都要面临分布式事务、链路追踪、服务间调用、配置管理这些原来单体不需要考虑的复杂度。先做扎实一个苍穹外卖这样的单体项目，再去做微服务方向，节奏是对的。面试时如果能说清楚“什么时候该拆、什么时候不该拆”，比一上来就说我会微服务更有说服力。

7. 最后分享几个实际操作的体会

整个苍穹外卖项目做下来，我最大的体会是：这个项目的价值不在于代码量，而在于它是一个能让你把“业务”和“技术”接上线的桥梁。很多人学了Spring Boot语法但不知道往哪用，学完这个项目就能理解一个真实的业务系统是怎么从需求变成了数据库表，再变成了接口，最后由前端把整个链路画成一个可以操作的产品。

我在做的过程中踩得最痛的坑是购物车、菜品缓存和订单状态这几个逻辑的相互纠缠。一开始我为了图快，把所有订单相关的逻辑都堆在OrderServiceImpl里，一个方法几百行，后面自己想加一个功能都要读半天代码。后来我花了半天时间把订单模块按“创建订单、支付回调、商家接单、配送、完成、取消、退款”拆成独立的方法和状态机，代码的可读性和可维护性明显提升。这个教训让我明白一件事：写代码前先腾出时间梳理清楚业务状态和模块边界，远比赶进度多写几个接口重要。

还有一个很实际的建议：如果你准备拿这个项目去面试，不要只盯着“我用了Redis、用了WebSocket”这些技术点说，而是要把自己放在一个真实的业务场景里去表达。比如面试官问Redis用在哪个场景，你就说是用来解决菜品的高频查询和购物车的临时存储，并说清楚为什么不用数据库直接扛、缓存更新策略是什么、极端情况如何兜底。这才是项目经验真正值钱的地方。

如果你也在做苍穹外卖，或者正在找一个能串起Java全栈知识的项目，希望这篇内容能帮你在动手前把整体脉络看清楚，少走我当初走过的那些弯路。