苍穹外卖Day10：用户下单全链路实现与踩坑复盘

我学苍穹外卖学到第10天，正好到了整个项目里最让我兴奋的一段——管理端那堆增删改查终于告一段落，从这天开始切入用户端真正的核心链路：从购物车勾选商品到生成订单、模拟支付，再到订单状态流转。day10的重头戏就是“用户下单”这个模块，前面9天学的JWT、公共字段自动填充、Redis缓存、事务处理，全都会在这段业务里串起来。这篇总结我打算按实际敲码顺序来写，把课堂笔记里没细讲的边界条件和踩坑点补出来。正在跟课的人可以当第二天的复习材料，没跟过课的人也能直观看到一个外卖项目的下单模块到底是怎么设计的。

1. 学完第9天之后，day10要啃的是什么

1.1 苍穹外卖的模块地图：管理端和用户端的分界线

苍穹外卖整体分成两大块。管理端是给门店员工用的，功能包括员工登录、员工管理、分类管理、菜品管理、套餐管理、店铺营业状态、订单管理；用户端是给小程序用户用的，包括微信登录、浏览菜品、购物车、地址簿、提交订单、支付、订单查询。这个划分不是随便分的，它对应的是“后台管内容，前台做交易”的典型业务结构。

跟我学的这个版本里，第9天结束时管理端基本完工，用户端的登录和购物车也已经跑通了。为什么要把用户下单放到第10天？因为下单是整个项目里第一个真正涉及“多表写入 + 状态变化 + 外部交互”的业务。它不像菜品管理那样只对一张表做CRUD，而是同时要动购物车表、订单主表、订单明细表，还要处理支付状态和订单状态。换句话说，前面那些模块是在教你怎么写单个接口，day10开始教你怎么写一条业务链路。

1.2 day10的目标清单：从购物车到支付成功的完整链路

这一天我的任务拆开看其实很清楚：

• 购物车确认页的数据准备（购物车列表 + 地址簿列表）
• 提交订单接口：校验地址和购物车、构造订单主表、构造订单明细、清空购物车
• 模拟支付：把订单从“待付款”推到“待接单”
• 订单号生成规则和状态字段的设计

清单看起来不多，但每一步都有坑。尤其是“提交订单”这个接口，它不像之前的接口那样只对一个表操作，事务边界如果没想清楚，后面查数据的时候会发现各种灵异现象：订单主表插进去了，明细表是空的；购物车被清空了，但订单没生成；订单生成了，但前端拿到的订单id是错的。这些问题我这一整天基本都遇到了。

2. 下单前置数据：购物车和地址簿是怎么准备的

2.1 购物车表为什么放在MySQL，而不是Redis

很多人一看到“购物车”三个字就下意识觉得应该用Redis，毕竟Redis的Hash结构天生适合存购物车，而且速度快、过期时间也方便。但苍穹外卖这个项目里，购物车表是放在MySQL里的，表名shopping_cart，核心字段大致这样：

为什么放在MySQL？最直接的原因是：购物车数据和订单流程强关联，提交订单时要把购物车数据读出来做订单明细，然后在同一个事务里清空购物车。如果购物车放在Redis，那订单的service方法里就要同时操作MySQL和Redis，事务就不好控制了——MySQL的事务管不到Redis，万一订单写成功了、Redis购物车清空失败，用户下次打开购物车会发现已经下过单的商品还在里面，非常尴尬。

当然Redis也不是完全不能用，真实高并发场景下购物车放Redis是很常见的做法，但需要一个补偿机制或者可靠的消息队列来保证最终一致性。苍穹外卖作为教学项目，把购物车放MySQL是更稳妥、更好理解的选择，也方便初学者用一套事务搞定所有写操作。

这个表还有一个值得注意的点：name、image、amount这些信息是从菜品表或者套餐表冗余进来的。为什么不直接只存dish_id，需要展示的时候再去查菜品表？因为购物车列表页面需要一次性展示名称、图片、价格、数量，如果只存id，每次查列表都要join菜品表和套餐表，还要判断到底是菜品还是套餐，SQL写起来非常啰嗦。冗余字段就是拿空间换查询效率，这个思路在订单明细表里会再次出现。

2.2 地址簿的默认地址逻辑：两个update的事务问题

地址簿表address_book，核心字段包括收货人、手机号、省市区、详细地址、标签，还有一个关键字段is_default，0表示非默认，1表示默认。一个用户最多只能有一个默认地址，这个约束不是靠数据库唯一索引实现的，而是靠业务代码控制的。

设置默认地址的mapper要做两个update：先把当前用户所有地址的is_default置为0，再把目标地址的is_default置为1。为什么要分两步？如果直接只更新目标地址为默认，而用户之前已经有一个默认地址，那就会出现两个is_default=1的地址，前端展示的时候就会判断混乱。如果只把原来的默认清掉而不设置新的默认，用户就会突然没有默认地址。

这两个update必须在同一个事务方法里执行，否则第一步成功了第二步失败了，用户就失去了默认地址。我当时第一次写的时候没加@Transactional，测试时倒也没出问题，因为本地数据量小，两步操作间隔极短。但后来我模拟人为把第二步的SQL改成语法错误，就发现第一步已经把默认地址清掉了，数据库里没有默认地址，二次下单的时候联调出现问题。所以这种“先清后设”的逻辑，事务是必须的。

2.3 结算页回显：后端视角的“数据拼装”

下单前的结算页，前端要展示购物车商品列表、收货地址列表、配送费和总金额。后端需要提供两个查询接口：一个查当前用户的购物车列表，一个查当前用户的地址簿列表。这里没有单独设计一个“结算页聚合接口”，前端拿到这两个列表自己拼页面，简化了后端接口设计。

有一点要特别注意：苍穹外卖的下单是默认一键下单全部购物车商品，不支持多选。所以提交订单时，前端参数只需要传一个addressBookId，购物车商品不需要传。有些人习惯性地想传一个商品id数组，反而是画蛇添足。后端拿到addressBookId后，会自己根据当前登录用户去查购物车表，把全部商品作为订单内容。

这个设计在需求层面是合理的，但这个隐含约定很容易被忽略。如果以后要扩展多选购物车下单，那提交订单的DTO里就需要增加购物车条目ids字段，后端查询时改成where id in (...) and user_id = ?，权限控制不能丢。

3. 提交订单的service实现：事务、状态与自增主键回填

3.1 submitOrder()的代码骨架

这一天最核心的代码就是OrderServiceImpl里的提交订单方法。我把它简化成骨架放在下面，实际项目里还有各种常量类和异常类，核心逻辑是这样的：

java复制@Service
@Slf4j
public class OrderServiceImpl implements OrderService {

    @Autowired
    private ShoppingCartMapper shoppingCartMapper;
    @Autowired
    private AddressBookMapper addressBookMapper;
    @Autowired
    private OrderMapper orderMapper;
    @Autowired
    private OrderDetailMapper orderDetailMapper;

    @Transactional(rollbackFor = Exception.class)
    @Override
    public OrderSubmitVO submitOrder(OrderSubmitDTO orderSubmitDTO) {
        Long userId = BaseContext.getCurrentId();

        // 1. 校验地址簿
        AddressBook addressBook = addressBookMapper.getById(orderSubmitDTO.getAddressBookId());
        if (addressBook == null) {
            throw new AddressBookBusinessException("地址不存在，请重新选择");
        }

        // 2. 查询当前用户购物车
        List<ShoppingCart> shoppingCartList = shoppingCartMapper.listByUserId(userId);
        if (CollectionUtils.isEmpty(shoppingCartList)) {
            throw new ShoppingCartBusinessException("购物车为空，不能下单");
        }

        // 3. 构造订单主表
        Orders order = new Orders();
        order.setNumber(UUID.randomUUID().toString().replace("-", ""));
        order.setStatus(Orders.PENDING_PAYMENT);
        order.setUserId(userId);
        order.setAddressBookId(addressBook.getId());
        order.setPhone(addressBook.getPhone());
        order.setConsignee(addressBook.getConsignee());
        order.setAddress(
                (addressBook.getProvince() == null ? "" : addressBook.getProvince())
                + (addressBook.getCity() == null ? "" : addressBook.getCity())
                + (addressBook.getDistrict() == null ? "" : addressBook.getDistrict())
                + (addressBook.getDetail() == null ? "" : addressBook.getDetail()));
        order.setOrderTime(LocalDateTime.now());
        order.setPayStatus(Orders.UN_PAID);
        order.setAmount(
                shoppingCartList.stream()
                        .map(item -> item.getAmount().multiply(new BigDecimal(item.getNumber())))
                        .reduce(BigDecimal.ZERO, BigDecimal::add));

        orderMapper.insert(order);

        // 4. 构造订单明细并批量插入
        List<OrderDetail> orderDetailList = shoppingCartList.stream().map(cartItem -> {
            OrderDetail detail = new OrderDetail();
            detail.setOrderId(order.getId());
            detail.setDishId(cartItem.getDishId());
            detail.setSetmealId(cartItem.getSetmealId());
            detail.setName(cartItem.getName());
            detail.setImage(cartItem.getImage());
            detail.setNumber(cartItem.getNumber());
            detail.setAmount(cartItem.getAmount());
            return detail;
        }).toList();
        orderDetailMapper.insertBatch(orderDetailList);

        // 5. 清空购物车
        shoppingCartMapper.deleteByUserId(userId);

        // 6. 组装返回VO
        return OrderSubmitVO.builder()
                .id(order.getId())
                .orderNumber(order.getNumber())
                .orderAmount(order.getAmount())
                .orderTime(order.getOrderTime())
                .build();
    }
}

这个方法的执行顺序是经过考虑的。先校验地址，再查购物车，这两个是前置条件，任何一个不满足都不能继续。然后是构造订单主表并insert，接着构造明细并批量insert，最后清空购物车。所有步骤都在同一个事务里，任何一个环节抛异常，已经执行的数据库操作都会回滚。

3.2 事务边界：主表和明细表要么一起成功，要么一起回滚

订单主表orders存的是订单的整体信息：订单号、用户id、地址信息、订单金额、订单状态、支付状态、下单时间。订单明细表order_detail存的是订单里每一种商品的信息：属于哪个订单、哪个菜品或套餐、名称、图片、数量、单价。两张表通过order_id关联，是一对多的关系。

为什么要分开两张表？仔细想一下，一个订单可能包含多个菜品和一个套餐，每一条商品项的价格、数量、名称都不同。如果把所有商品信息拼成一个字符串塞进orders表的一个字段里，那后续商家接单页面、历史订单页面、订单详情页面都难以单独查询和统计。拆成主表和明细表，是关系型数据库处理这种“订单-订单项”结构的标准做法。

在事务之外还有一个重要的设计细节：订单明细里的name、image、amount都是从购物车冗余过来的快照，而不是下单时再去查菜品表。这意味着什么呢？如果下单之后，门店把菜品的价格从30元调成了35元，用户的历史订单详情里显示的还是下单那一刻的30元。对用户来说这是必须的，订单是交易凭证，不能因为商家改价而变来变去。菜品的当前价格是“现价”，订单里的价格是“成交价”，这两者必须分开，否则财务对账会对不上。

事务注解这里我写的是@Transactional(rollbackFor = Exception.class)，这个细节很关键。Spring事务默认只回滚RuntimeException和Error，如果业务方法里抛出了Checked Exception（比如IOException），事务并不会回滚。虽然这个接口里不会主动抛出受检异常，但养成写rollbackFor = Exception.class的习惯能避免很多奇怪的线上问题。

3.3 主键回填与批量insert：几个容易忽略的细节

主键回填是这节最容易踩的坑。订单主表orders的id是数据库自增主键，insert之前Java对象里id是null。想让insert之后order.getId()自动变成数据库生成的主键，必须在MyBatis的insert标签里配置useGeneratedKeys和keyProperty：

xml复制<insert id="insert" parameterType="com.sky.entity.Orders"
        useGeneratedKeys="true" keyProperty="id">
    INSERT INTO orders (...)
    VALUES (...)
</insert>

这个配置含义是：数据库生成的自增主键，回填到传入参数的id属性上。如果不写，order.getId()永远为null，后面构造OrderDetail时设置orderId就会是null。如果order_detail表的order_id字段没有非空约束，订单明细也会静默插入成功，但查出来的内容根本关联不到订单；如果有非空约束，这里会直接报SQLException。我第一次跑通的时候，就是因为没配useGeneratedKeys，明细表全是order_id为null的脏数据，排查了好久。

订单明细表插入用的是批量插入：

xml复制<insert id="insertBatch" parameterType="list">
    insert into order_detail
    (order_id, dish_id, setmeal_id, name, image, number, amount)
    values
    <foreach collection="list" item="od" separator=",">
        (#{od.orderId}, #{od.dishId}, #{od.setmealId},
         #{od.name}, #{od.image}, #{od.number}, #{od.amount})
    </foreach>
</insert>

不要在一个循环里单条insert，数据库连接和事务开销会成倍增加，在订单项多的时候性能会很难看。如果以后项目里数据量上来，还可以在JDBC连接串上加上rewriteBatchedStatements=true，让MySQL驱动把一批语句合并成一条多值insert发送，性能提升很可观。

4. 模拟支付与订单状态机：最容易被忽略的一环

4.1 模拟支付是怎么落的

真实项目里，支付要对接微信支付或支付宝，需要商户号、证书、回调验签等一整套东西。教学项目不可能让每个学员都去申请商户资质，所以苍穹外卖做了模拟支付的处理：前端点“去支付”，后端直接把订单状态更新成“已支付”，模拟一次支付成功的回调。

模拟支付的实现不复杂，但有一个原则必须守住：支付接口必须校验当前订单状态确实是“待付款”。如果订单已经支付过了，再来一次支付操作不能把它从“已支付”改成“已支付”这种无意义的重复，更不能把金额再叠加一次。核心代码大概是：

java复制public void payOrder(Long orderId) {
    Orders order = orderMapper.getById(orderId);
    if (order == null) {
        throw new OrderBusinessException("订单不存在");
    }
    // 只在待付款状态下才能支付成功
    if (order.getStatus() != Orders.PENDING_PAYMENT) {
        return;
    }
    // 状态更新成待接单
    Orders update = new Orders();
    update.setId(orderId);
    update.setStatus(Orders.PENDING_CONFIRM);
    update.setPayStatus(Orders.PAID);
    update.setPayTime(LocalDateTime.now());
    update.setCheckoutTime(LocalDateTime.now());
    orderMapper.update(update);
}

注意这里有个“待付款”到“待接单”的状态跳跃。为什么支付成功不是直接改成“已完成”？因为用户付完钱，商家还没接单、还没配送，订单生命周期才刚走了一半。很多新手在状态字段这里容易糊弄过去，觉得支付成功就完事了，实际上后面还有商家端的一堆操作依赖这个状态。

4.2 订单状态字段与状态机流转

苍穹外卖里订单状态是一个int字段，不同值代表不同阶段，最常见的一套定义是这样的：

状态流转是有方向的。1可以流向2或者6，2可以流向3或者6，3流向4，4流向5。不能出现从1直接跳到5这种匪夷所思的流转。在实际编码中，状态的每次变化都要做前置校验，确保当前状态允许跳转到目标状态，而不是无脑set一个新值。

建议学到这里的时候，自己把状态流转图画在纸上（用文字列出每个状态允许跳转到哪些状态），写代码时对照着来。我踩过一次坑：用户支付接口没校验状态，导致一个已经“已完成”的订单被二次支付接口又把状态改回了“待接单”，数据库里出现了一个时间线错乱的神奇订单。从那以后，所有状态更新我都强迫自己写条件更新。

4.3 回调幂等：同一个支付通知来了两次怎么办

模拟支付可以手动调用，真实支付场景里，支付平台的通知是可能重复发送的。网络超时、商户端处理失败、平台重试机制，都会导致同一个支付成功的通知到达两次甚至更多次。如果后端处理逻辑不是幂等的，就可能出现：订单状态被重复更新、支付时间被覆盖、用户被重复发货这种事故。

怎么保证幂等？一个简单可靠的做法是在更新SQL里带上状态条件：

sql复制update orders
set status = 2, pay_status = 1, pay_time = #{now}, checkout_time = #{now}
where id = #{orderId} and status = 1 and pay_status = 0

如果当前订单已经不是待付款状态，这个update影响行数为0，代码里根据int rows判断一下，为0就直接返回成功，不做任何操作。这样第二次通知到达时，订单已经是“待支付成功”状态，条件不满足，update影响0行，完美跳过。

这个方案比“先select再update”更稳，因为select和update之间可能有并发间隙，条件更新把判断和修改合并成了一步，从根上消除了竞态条件。类似的思路在后面对接真正的支付回调时也一样适用。

5. 下单接口的黑盒测试与并发小考

5.1 用Postman走通完整链路

写完代码，我用Postman跑通了一遍完整的下单链路，推荐你也这样做一遍，比只看控制台日志直观得多。步骤大概是：

1. 调用登录接口获取token，苍穹外卖里是POST /user/user/login，拿着小程序登录code换token。
2. 调用添加购物车接口POST /user/shoppingCart/add，body里传dishId或者setmealId。
3. 调用查询购物车接口GET /user/shoppingCart/list，确认商品在购物车里。
4. 调用添加地址簿接口POST /user/addressBook，把收货人、手机号、地址填上。
5. 调用提交订单接口POST /user/order/submit，body里只传addressBookId。
6. 调用模拟支付接口，传入订单id。
7. 调用订单详情接口，核对状态和金额。

跑通之后，去数据库里看两张表。orders表里应该有一条状态为2、支付状态为1的记录，order_detail表里有对应的商品明细，购物车shopping_cart里该用户的记录已经被清空。这一步一定要亲眼看到数据变化，才能确认事务和状态更新真的按预期工作。

测试的时候建议把MyBatis的SQL日志打开，在application.yml里配置logging.level.com.sky.mapper=debug。这样控制台会打印每次执行的SQL和参数，哪个SQL先执行、哪个SQL后执行、insert之后主键是什么，一目了然。排查主键回填问题的时候这个日志能省一半时间。

5.2 快速连点提交按钮，会发生什么

一个隐藏比较深的问题是重复提交。前端如果不在点击“提交订单”按钮后做loading禁用，用户手快连续点两下，就会发出两个下单请求。后端两个请求同时进来，都查出购物车不为空，都插入一条订单，都执行清空购物车。最后用户发现自己下了一模一样的两单，多付一份钱。

解决这个问题的常见思路有三个：

第一，前端按钮防抖。点击后立即disable，等接口返回再恢复。这是最简单也最常用的一层防护，但只靠前端不保险，懂技术的人绕过前端直接调接口，防不住。

第二，后端幂等令牌。前端在进入结算页时向后端申请一个唯一的token，下单时带着这个token，后端用一个唯一索引或Redis来保证同一个token只能下单一次。这个方案是正路，但教学项目里一般不展开。

第三，Redis分布式锁。以下单用户id作为key，用setnx设置一个短过期时间的锁，拿到锁才能执行下单逻辑，执行完释放。这个思路面试时经常被问，可以作为加分项讲给面试官听。

5.3 锁与隔离：这里需要引入悲观锁吗

有些人在做下单时第一反应是给购物车或订单表加悲观锁（select ... for update），这种思路在这个场景里是过度设计。购物车和订单都是用户维度的数据，同一个用户同时提交两笔订单的概率极低，而且就算出现了，靠前端防抖和后端幂等方案也能解决，不需要动数据库锁。

真正需要悲观锁或乐观锁的场景是库存扣减。比如一个商品只剩最后一件，两个用户同时下单，如果不加控制，两个订单都会扣减成功，导致超卖。这时候通常是扣库存SQL里带库存条件：update sku set stock = stock - 1 where id = ? and stock >= 1，利用数据库行锁保证同一行只有一个扣减成功。但外卖项目没有这种库存强约束，菜品卖完可以报“已售罄”，不涉及超卖问题，所以下单接口不需要悲观锁。

这里想清楚“什么场景该加锁、锁在哪个粒度”，比盲目加锁重要得多。看到两层含义：一个是对锁的理解，另一个是对业务边界的管理。

6. 我在day10踩过的坑和复盘

6.1 Long转Json丢精度：前端订单id后几位全是0

这是整个day10最典型的坑。订单主键id是数据库自增long，但苍穹外卖的订单id在真实代码里往往走的是雪花算法或者类似的长整型id策略，位数很长。前端JavaScript的Number类型只能精确表示2^53以内的整数，更大的数字会丢精度。

具体表现是：接口返回的订单id是7344998832000008192，浏览器端console里显示7344998832000008000，后几位变成了0。用这个id去调订单详情接口，后端按id查数据库，发现查不到。明明刚下的单，详情就是打不开。

解决办法有很多，最常见的是在实体类的id字段上加上：

java复制@JsonSerialize(using = ToStringSerializer.class)
private Long id;

这样Jackson在序列化这个字段时会把Long转成字符串输出，前端就不会丢精度了。另一种做法是全局Jackson配置把所有Long都转String，但副作用是所有Long类型的字段都会变成字符串，某些场景下前端又需要数字做计算，就不太方便。所以我倾向于只对id类字段注解。

这个坑在day10之前不会暴露，因为之前课程里的接口返回的主键数字比较小，前端不敏感。到了订单模块，订单id是贯穿各页面的关键标识，这个坑就变得非常致命。

6.2 @Transactional自调用失效

事务失效的问题我在第3章提过一嘴，这里展开说。Spring的声明式事务是基于AOP代理实现的，被@Transactional标记的方法在被调用时，Spring会通过代理对象增强事务逻辑。但是如果同一个类里的一个普通方法调用了另一个被@Transactional标记的方法，这个调用是this.method()，不会经过代理对象，事务注解就完全不生效。

我当时的代码踩过这个坑：submitOrder方法本身没加注解，里面调用了一个私有方法saveOrderWithDetails，在这个私有方法上加了@Transactional。表面上看起来有事务，实际执行时每个SQL都是独立提交的，明细表插入成功后如果清空购物车失败，明细表依然留在数据库里。排查这个问题时翻了很多资料才意识到是代理失效。

正确的写法是：事务注解加在外部入口方法上，也就是controller直接调用的那个service方法，而且遇到异常会回滚，所以注解要加在submitOrder()上，内部方法不要重复加，加了没用还容易误导人。

6.3 空购物车下单的校验顺序

代码里要先校验地址还是先校验购物车？两种顺序都能实现功能，但用户体验差别很大。如果用户还没添加地址就提交订单，期望的提示当然是“请先添加收货地址”；如果购物车是空的还提交订单，期望的提示是“购物车为空”。这两种情况同时发生时，先校验哪个就决定了用户看到的第一个错误提示。

我建议先查购物车、再查地址簿。原因很直接：购物车是下单的基础，购物车都没有，下单这个动作就没有意义，没必要再浪费一次数据库查询去查地址。而且购物车为空时用户大概率知道自己还没选餐，提示购物车为空更友好。如果反过来先查地址，地址不存在时用户可能一头雾水：我给用户下个单，怎么先让我填地址？

另外，判断购物车为空一定要用CollectionUtils.isEmpty()，不要用cartList == null。MyBatis的列表查询方法通常返回的是空List而不是null，用== null判断永远进不了异常分支，下单流程会带着空的购物车列表继续执行，最后生成一个金额为0的瘸腿订单。

6.4 学到这里再看“苍穹外卖”，它在教什么

day10给我的整体观感是：苍穹外卖的大部分课程时间花在管理端CRUD上，但真正让这个项目有“业务感”的，恰恰是用户下单到支付这一小段。管理端的分类管理、菜品管理，本质上就是在维护一张张字典表和商品表，谁都能写，区别只在代码规范。而下单模块涉及事务、幂等、状态机、并发控制，这些东西才是程序员拉开差距的地方。

我学完这一天后养成了一个习惯：每完成一个业务模块，就把这个模块涉及的状态流转和关键表关系整理成一张表格贴在自己的笔记里，而不是直接抄代码。因为代码会忘，但状态流转图和表关系图不会。后面再学管理端订单接单、派送、完成，你会发现全部是在day10定的这套状态机上做扩展，新增几个状态分支而已。基础打扎实了，后续都是顺水推舟。