1. 项目概述苍穹外卖DAY6这天我在做什么先说结论苍穹外卖这套实战项目DAY6的核心内容其实是把订单从用户手里接进来再稳稳当当送出去这条链路的第一个大节点——用户下单、支付回调、订单状态流转。如果你跟着课程或文档一路写到这里前面几天大概已经搞定了员工端、分类管理、菜品管理这些后台CRUD到了DAY6才真正进入C端核心逻辑代码量和业务复杂度会明显上一个台阶。DAY6这一天我的实际工作可以拆成三块用户端接口购物车、地址簿、下单这三个模块的接口设计从DTO/VO定义到Controller、Service、Mapper全链路打通。订单核心流程创建订单涉及主表明细表地址快照、支付回调处理这里用的是微信支付模拟流程、订单状态自动更新。定时任务初体验使用Spring Task实现超时未支付订单自动取消和完成订单自动派送这两个定时任务。如果你正在刷苍穹外卖或者在做类似的电商/外卖类实战项目这一天值得认真对待。因为订单表设计、状态机流转、事务边界处理这些东西不只是这个项目要用的放到任何带交易性质的系统里都一样是核心难点。我印象最深的是DAY6的代码量其实没有前面几天多但调试时间反而翻倍。原因很简单——订单流程是个跨表、跨方法、跨模块的链路任何一个环节的小疏忽比如状态值写错、事务没生效、异步任务没触发排查起来都会让你怀疑人生。下面我把DAY6的完整思路、踩坑记录、代码关键点全部摊开讲适合正在写这个项目的人对照参考也适合想搞懂外卖系统订单模块到底怎么设计的人读。2. 下单链路拆解从购物车到订单落库到底经历了什么2.1 数据模型设计订单主表与明细表为什么必须分开先说一个很多新手会忽略的问题订单数据为什么要拆成order主表和order_detail明细表而不是直接存一个JSON字符串了事答案很实在一张表存全部字段查询和统计会变得极其痛苦。比如你要查这个月销售额是多少如果所有商品都塞在订单表的一个字段里那你得先把每条订单的商品数据解析出来再聚合这不是查数据库这是在写解释器。拆成主表和明细表之后订单主表存一次交易的整体信息订单号、金额、状态、收货地址、下单时间明细表存这笔订单包含的每一种商品商品名、数量、单价、小计主表和明细表通过order_id关联。DAY6的订单实体设计大致长这样Orders主表id、订单号、订单状态、下单时间、结账时间、支付状态、支付时间、订单金额、实收金额、收货人、电话、地址、备注、用户id、商家id等。OrderDetail明细表id、订单id、商品id、商品名称、商品图片、商品单价、商品数量、商品小计。要注意的是明细表里除了商品id还冗余保存了商品名称、商品图片、单价这些快照字段。这是因为商品信息后续可能被修改改名、调价、下架但历史订单必须保持下单那一刻的样子。这个思想叫数据快照在电商订单设计里是标配操作。2.2 下单接口的完整调用链Controller到Mapper的每一步DAY6下单接口的核心逻辑我画一条调用链出来你就明白了用户提交下单请求 → 接收下单DTO包含地址簿id、支付方式、备注、预计送达时间等 → 校验参数合法性 → 根据用户id查询购物车列表 → 如果购物车为空直接抛业务异常 → 构造订单主表数据生成订单号、设置初始状态、计算总金额 → 批量插入订单明细数据 → 清空当前用户的购物车 → 封装并返回下单VO包含订单号、实付金额等这中间有几个关键设计点订单号生成。DAY6用的是时间戳用户id后几位之类的拼接方式但实际商用系统一般会用更复杂的规则比如雪花算法、分段发号器避免高并发下订单号冲突。做项目可以简单点但要理解背后的原因。金额计算。总金额不是前端传过来的而是后端根据购物车里的商品单价和数量重新计算。前端传金额只作为一种展示参考绝不能直接信任。你在DAY6代码里会看到类似amount sum(price * number)的循环累加逻辑这个非常重要。状态初始值。下单成功时订单状态置为待付款状态值1支付状态置为未支付状态值0。后面支付回调成功后才改成待接单和已支付。事务边界。插入主表、插入明细、清空购物车这三步必须在一个事务里。如果主表插入成功但明细插入失败最后购物车还被清了那就真出大事了。DAY6在Service层加了Transactional注解但注意这个注解的失效问题后面我会单独讲。2.3 下单模块的DTO/VO设计接口参数与返回值的边界这里补充一个容易被忽略但非常实用的细节DTO和VO各司其职不要混用。DTO数据传输对象接收前端请求参数比如OrdersSubmitDTO包含地址簿id、支付方式、备注、预计送达时间。前端不需要传订单状态、订单号这些后端才能生成的东西。VO视图对象返回给前端的数据比如OrdersSubmitVO包含订单号、实付金额、预计送达时间等。后端内部使用的实体类不一定原样返回给前端避免把内部字段泄露出去。很多初学者图省事直接从Controller接收实体类然后把实体类原样返回。这在单体小项目里勉强能用但一旦前后端联调、接口文档对接起来你会发现自己被字段耦合死死绑住——前端多要一个字段你要改实体类后端内部加个字段前端也会看到。DAY6用DTO/VO隔离之后接口的稳定性和可维护性都会明显好很多。3. 支付回调和订单状态流转最容易翻车的一段流程3.1 微信支付模拟流程回调接口到底在回调什么DAY6因为是在本地开发环境接不了真实的微信支付所以用的是模拟支付回调。但模拟不代表你可以把流程糊弄过去相反你更要把回调的机制理解透。真实场景下微信支付的大致流程是用户下单后前端调用后端接口后端向微信支付平台发起预下单拿到一个支付链接或支付参数。前端唤起微信支付用户在微信里完成付款。微信支付平台异步通知后端服务器这就是回调通知内容是订单号、支付结果、金额等。后端在回调接口里校验签名、核对金额、更新订单状态。同步给前端返回结果前端轮询订单状态刷新页面。DAY6的模拟逻辑则简单得多前端在支付成功后直接调用后端的支付回调接口后端收到请求后把订单状态从待付款改成待接单支付状态改成已支付同时记录支付时间。虽然少了签名校验、预付单这些真实环节但状态流转的核心逻辑是一样的。3.2 状态改变的事务与幂等性为什么同一个回调不能执行两次这里我要花点篇幅讲一个DAY6可能没有刻意强调、但实际开发中极其重要的东西——回调接口的幂等性。假设用户支付成功了微信支付平台回调了你的接口你的接口执行了更新订单状态为已支付。一切正常。但如果因为网络抖动回调通知发了两次你的接口被调用两次会发生什么如果代码是简单的order.setStatus(PAID); orderMapper.update(order);第二次回调会把状态又从待付款改成已支付吗不会因为第一次已经改成已支付了第二次只是再改一次而已看起来没问题。但问题在于如果回调里除了改状态还有别的操作比如通知商家、给用户发优惠券、记录支付流水那第二次执行就会产生重复数据。DAY6的解决方案是在回调处理里先根据订单号查询当前状态如果已经不是待付款直接return不再重复处理。这个先查再改的防御性写法就是幂等控制的最朴素实现。真实商用系统还会用数据库唯一约束、分布式锁、消息队列去重等方式加强但思想是一样的。状态机的设计也应该遵循只能单向流转原则待付款 → 待接单 → 已接单 → 派送中 → 已完成以及待付款超时 → 已取消。允许待付款直接跳到已完成在业务上是说不通的。3.3 顾客端查询订单状态状态值映射与超时判断订单支付完成后前端需要轮询或下拉刷新查看订单状态。DAY6在顾客端订单查询这里会做一件事——动态判断订单是否超时未支付并实时更新状态。这里有个常见误区有人会把修改超时未支付订单状态寄托在前端判断上。比如前端拿到订单的时间发现过了15分钟还没支付就显示已取消。这不对。状态必须以后端为准前端只是展示后端返回的状态值。所以DAY6的做法是定时任务每天/每几分钟扫描所有待付款状态的订单。如果下单时间距当前时间超过15分钟就把状态更新为已取消。在用户查询订单列表时返回给前端的是实时计算后的状态即后端在返回前先扫描更新一遍确保用户看到的不是过期状态。这个先更新再查询的思路在订单这类时效敏感的业务里非常常见。你写代码的时候可以专门把计算订单实际状态这个方法单独抽出来复用避免定时任务和查询逻辑各写一套导致状态不一致。4. 购物车与地址簿订单前置模块的细节打磨4.1 购物车接口的四个动作增、删、改、查DAY6的购物车模块相对简单但它是订单流程的入口逻辑不能马虎。购物车核心接口有四个接口动作请求方式核心逻辑加入购物车POST根据用户id商品id查询是否已存在存在则数量1否则新增记录查看购物车GET按用户id查询全部商品按创建时间倒序排列修改购物车数量POST根据id和数量字段要么加一要么减一减到0就删除记录清空购物车DELETE下单成功后调用删除当前用户所有购物车记录这里最值得琢磨的是加入购物车的去重逻辑。核心sql就是SELECT * FROM shopping_cart WHERE user_id #{userId} AND dish_id #{dishId}查到就setNumber(number 1)没查到就新增一条记录number默认为1。这个先查再增的逻辑虽然简单但要注意并发问题——如果用户疯狂点击加入购物车两次请求同时进来都查不到记录就可能插入两条重复数据。DAY6这种学习项目一般不做额外处理但你要知道真实系统里这里会加唯一索引或用数据库锁来防重。4.2 地址簿的默认地址逻辑每次下单都要注意的坑地址簿模块本身不复杂就是一个CRUD但有一个点很值得注意——默认地址的设置逻辑。DAY6里地址簿表的常见设计是加一个is_default字段1表示默认地址0表示非默认。新增地址时如果用户还没有任何地址第一条就自动设为默认地址如果用户已经有默认地址又把新地址设为默认那原来的默认地址要取消掉。我第一次写的时候就在这里踩坑了直接写SQL把新地址is_default改为1结果用户有了两个默认地址。后来改成两段式更新-- 先把该用户所有地址的默认标记清零 UPDATE address_book SET is_default 0 WHERE user_id #{userId}; -- 再把指定地址设为默认 UPDATE address_book SET is_default 1 WHERE id #{id};这两个操作同样要放在一个事务里防止第一步成功第二步失败导致一个默认地址都没有。另外下单时地址是直接关联地址簿id还是把地址快照存到订单表DAY6的具体做法我记得是订单表冗余存储了收货人姓名、电话、详细地址这些字段而不是只存一个地址簿id。这个设计和明细表冗余商品信息是一个道理——地址后续可能被用户修改但订单必须保留下单那一刻的收货信息。如果只存地址簿id用户下单后改了地址你就不知道这份订单到底该往哪送了。4.3 前端联调时的常见问题字段缺失与类型不匹配购物车和地址簿在DAY6属于偏前置的业务模块前后端联调时最容易出现的问题是字段名不一致后端VO里叫amount前端代码里用totalAmount结果页面一直显示0。这种问题排查半天结果就是两边字段名对不上。金额类型丢失精度数据库用decimalJava用BigDecimal但JSON序列化之后前端拿到的可能是数字小数位被截断。DAY6里金额我建议统一保留两位小数接口返回时格式化好前端不要自己做四舍五入。null值问题比如地址簿里没有设置默认地址的用户isDefault字段返回null前端判断时直接null 1逻辑出错。如果你在做前后端分离开发建议定义一个统一的返回格式比如Result类的code、msg、data所有接口都走这个格式。遇到问题先打印接口返回的JSON再看前端控制台报错别上来就改代码。5. 超时取消与自动派送Spring Task定时任务实战5.1 Spring Task入门三行代码实现定时任务DAY6的定时任务用的是Spring Task不是Quartz。它最大的优点就是轻量一个EnableScheduling开启调度一个Scheduled注解定义执行规则三行代码就能跑起来Component public class OrderTask { Scheduled(cron 0 * * * * ?) // 每分钟执行一次 public void processTimeoutOrder() { // 查询超时未支付订单改成已取消 } Scheduled(cron 0 0 1 * * ?) // 每天凌晨1点执行 public void processFinishedOrder() { // 查询派送中超过一定时间的订单改成已完成 } }cron表达式里那个六个/七个字段的顺序新手经常搞混。我个人的速记法是秒 分 时 日 月 周。比如0 0 1 * * ?就是每天1点0分0秒执行0 * * * * ?就是每分钟第0秒执行。5.2 定时任务里的SQL编写状态时间双重条件定时任务本身不难难在SQL条件怎么写。处理超时未支付订单的SQL大致是UPDATE orders SET status 6, cancel_time NOW(), cancel_reason 超时未支付系统自动取消 WHERE status 1 AND pay_status 0 AND order_time DATE_SUB(NOW(), INTERVAL 15 MINUTE);注意三点必须同时限定status和pay_status防止把已经支付但状态没来得及更新的订单误取消。时间比较要用数据库时间或服务器时间不要用代码里自己new的Date保证多个定时任务实例之间不会因为时间不同步产生偏差。扣掉15分钟要用DATE_SUB而不是在代码里算好再传参这样SQL可读性和维护性更好也方便以后调整超时阈值。自动派送的任务逻辑类似UPDATE orders SET status 4 WHERE status 3 AND estimated_delivery_time NOW();也就是说订单状态为派送中3但预计送达时间已经过了就自动改成已完成4。当然真实业务里派送完成应该由骑手端确认定时任务只能作为兜底策略防止状态长期卡住不更新。5.3 定时任务偶发性失效排查思路与注意事项DAY6里如果定时任务没有生效我的排查顺序是这样的启动类有没有加EnableScheduling。这个注解漏掉Scheduled全部不生效而且不报错很容易漏。任务类有没有被Spring扫描到。Component没加或者包扫描范围不对任务类压根没进容器。cron表达式是否正确。比如把0 * * * * ?写成* * * * * ?任务就不是每分钟执行一次而是每秒执行一次。这种写法在开发环境危害不大但部署到生产环境会影响数据库压力。任务是否抛异常中断。Spring Task默认情况下如果任务执行抛出异常任务调度线程可能会被阻塞后续任务不再执行。最好在定时任务方法内部try-catch或者单独做一个异常记录表方便排查。另外一个容易被坑到的点多个定时任务同时执行时默认是单线程串行执行。如果一个任务卡住了比如SQL锁等待另一个任务也会被拖住。如果你的项目到了后面有多个定时任务建议配置一个简单的线程池让任务并行执行Configuration public class SchedulingConfig { Bean public TaskScheduler taskScheduler() { ThreadPoolTaskScheduler scheduler new ThreadPoolTaskScheduler(); scheduler.setPoolSize(5); return scheduler; } }这个配置在DAY6里可能用不上但你知道有这么回事就行以后做更复杂项目会用到。6. 事务与并发DAY6里最容易被忽视的隐藏地雷6.1 Transactional的五种失效场景DAY6的下单方法加了Transactional但注解加了不等于事务就生效。我盘点一下最常见的失效场景你照着检查自己的代码就能避开一大半问题方法被private修饰。Spring事务是通过动态代理实现的只有通过外部调用public方法时事务增强才会生效。同类内部调用private方法事务直接失效。类没有被Spring管理。即类上没加Service、Component等注解Spring不会创建代理对象自然没有事务。方法内部自调用。同一个类里方法A调用方法BB上有Transactional但A没有事务不会生效。因为调用发生在对象内部不走代理。异常被try-catch吞掉。事务默认只在RuntimeException时回滚如果你自己catch了异常不往外抛事务框架感知不到异常就会提交。数据库引擎不支持事务。比如MySQL的MyISAM引擎就没有事务支持要用InnoDB。DAY6的下单方法我建议这样写能避开大部分雷区Service public class OrderServiceImpl implements OrderService { Transactional(rollbackFor Exception.class) public OrderSubmitVO submit(OrdersSubmitDTO dto) { // 1. 校验购物车 // 2. 插入订单主表 // 3. 插入订单明细 // 4. 清空购物车 } }注意rollbackFor Exception.class这个属性。默认情况下Transactional只回滚RuntimeException如果你代码里抛的是CheckedException事务不会回滚这会让数据处于半写状态。显式声明回滚所有异常是最稳妥的。6.2 高并发下单场景超卖与重复下单问题DAY6是单体学习项目一般不会刻意模拟高并发。但你既然学到了订单模块这些东西迟早要面对超卖问题商品库存只有1件两个用户同时下单成功库存变成-1。解决思路数据库乐观锁UPDATE stock SET stock stock - 1 WHERE id ? AND stock 0利用受影响行数判断是否成功。重复下单用户手抖点了两次提交生成了两笔订单。解决思路前端按钮置灰防止连点后端可以加防重令牌或者在下单接口做幂等校验比如用用户id购物车hash判断短时间内是否重复提交。这些内容DAY6不一定要求实现但面试时很容易被问到提前理解不吃亏。6.3 事务边界到底该划在哪下单方法里能做多余的操作吗一个比较好的实践原则是一个事务方法只做和当前业务强相关的数据变更外部调用、异步任务、网络请求不要放在事务里。比如DAY6里下单成功后需要清空购物车这个清空操作和下单强相关放在同一个事务里没问题。但假设下单成功之后要调外部短信接口通知用户那我建议把短信调用放到事务方法外面。因为外部接口可能超时、可能失败如果放在事务里会让数据库连接一直被占用事务长时间不提交拖垮系统性能。你以后做项目如果发现某个接口响应特别慢先检查一下是不是在事务里做了太多跟数据库无关的事情比如发邮件、调第三方接口、解压文件。这些操作耗时越长事务占用的数据库连接就越久。7. 实战踩坑记录我这一天调试最久的三件事7.1 坑一购物车清空了订单却没生成现象下单接口报错回滚了但后面查购物车发现居然是空的。一开始我很懵逻辑顺序明明是插订单、插明细、清空购物车订单失败应该回滚购物车不会被清。排查过程打印日志发现走的不是回滚路径而是购物车清空先执行了。后来一查是因为我在Controller里先调用了清空购物车接口因为前端下单流程中先请求了清空购物车再请求下单两个接口之间有先后时序导致下单失败但清空操作已经被另一个事务提交了。教训前端调用顺序一定要和后端接口设计对齐。下单接口内部自带清空购物车逻辑前端就不要额外调一次清空接口否则会出现重复操作和事务边界混乱。7.2 坑二回调接口被重复调用订单状态错乱现象我本地调试时用工具连续触发两次支付回调结果订单状态直接跳过了待接单变成了派送中。这就是典型的状态机没有做单向流转校验。修复方式是在回调方法第一步就拦截Orders order orderMapper.getById(orderId); if (order null || !order.getStatus().equals(WAIT_TO_ACCEPT)) { log.warn(订单状态异常回调处理跳过{}, orderId); return; }后来我还加了个判断如果订单已经被取消回调也不能把订单改成已支付。在真实支付回调里已取消订单的支付结果要做退款处理这里不展开但你要有这个意识。7.3 坑三定时任务没触发以为是代码问题结果是cron写错了现象超时未支付订单过了20分钟还是待付款定时任务像没跑一样。排查过程先检查启动类注解没问题检查任务类扫描没问题最后把cron表达式拿出来一行一行看发现我写的是0 0 15 * * ? // 我以为这是“每15分钟执行一次”但按照cron语法这个表达式其实是每天15点0分0秒执行一次。那当然不会频繁触发。正确的每15分钟执行一次应该写成0 0/15 * * * ?说实话cron这东西不看文档纯靠自己记真的容易翻车。我建议在写完之后用在线cron表达式解析工具先验证一遍别直接部署。8. 订单模块的扩展思考DAY6之外还能做哪些优化8.1 从能用到好用状态机枚举化DAY6的订单状态大概率是用数字常量写到代码里的比如1代表待付款、2代表待接单。项目能跑但代码可读性很差——你看到order.getStatus() 1得去翻注释才能知道1是什么意思。我建议自己动手把它重构为枚举public enum OrderStatus { WAIT_PAY(1, 待付款), WAIT_ACCEPT(2, 待接单), ACCEPTED(3, 已接单), DELIVERING(4, 派送中), COMPLETED(5, 已完成), CANCELED(6, 已取消); private final Integer code; private final String desc; // 构造方法、getter }改完之后if (order.getStatus().equals(OrderStatus.WAIT_PAY.getCode()))这种写法一目了然后期扩展状态流转逻辑也方便。8.2 从同步到异步下单成功后的事件通知DAY6的下单、支付、接单都是同步调用。真实项目中订单状态变化往往需要通知多个下游系统比如通知商家、通知骑手、推送消息给用户这些操作如果全部同步执行接口响应会越来越慢。优化思路是引入消息队列下单成功后发布一个订单已创建事件由消费者异步处理后续操作。这个用Spring自带的ApplicationEvent也能做个简易版不需要依赖外部中间件适合自己练手加深理解。8.3 从单机到分布式订单号的全局唯一策略DAY6的订单号生成方式不提性能的话问题不大但对接支付平台后订单号在某些场景下会有严格约束比如微信支付要求商户订单号不能重复。以后做分布式部署时订单号生成就要考虑使用全局唯一ID方案。雪花算法是现在比较主流的方案它通过时间戳机器id序列号保证每秒能生成大量不重复ID而且趋势递增对数据库索引友好。这个现在不用写但你在简历上写熟悉订单号生成策略的时候至少能说出几种方案和它们的优缺点。9. 写在最后的几点体会DAY6这一天的工作量和前五天相比看起来只是多了一个订单模块但实际上是从管理后台跨入用户交易的关键转折点。这一天里我踩过的坑、修正过的思路有几个体会想留给你第一设计表结构时多留一个心眼。订单主表和明细表的拆分、快照字段的冗余这些设计看起来是多写几个字段的小事但到了统计报表、数据核对、问题追溯的时候你就会感谢当初的冗余设计。少一个快照字段等上线之后想补数据已经丢了。第二状态流转一定要画清楚再做。我见过很多项目在开发阶段不重视状态机等到联调阶段才发现已取消的订单还能被接单已完成的订单还能退款那时候改代码就要动一堆地方。DAY6虽然只有几个状态但你可以在纸上画一画每个状态的来源和去向心里有数再动手写。第三调试时不要死盯代码先把数据链路串一遍。我调支付回调那天卡了很久后来发现不是代码逻辑的问题而是订单状态在数据库里已经被之前的测试数据污染了。把数据库里的脏数据清掉、重新走一遍完整流程比反复打断点有效率得多。第四做项目不要满足于跑通。如果仅仅把接口调通、页面能点那DAY6的价值只发挥了三分之一。把事务失效的场景挨个测一遍把定时任务的时间调整几次看效果把状态枚举重构一遍这些主动做的事才是拉开差距的地方。苍穹外卖这个项目虽然是个教学项目但订单模块的设计思路和坑点放到真实系统里一样适用。我写完DAY6之后最大的感受是外卖系统的难度不在于某个技术点有多深而在于业务链条太长、状态太多、分支太杂。把这些理顺了后面再做别的业务系统会顺很多。