鲜奶订购系统的核心设计：从订阅周期建模到配送日历实现

1. 这个题目的核心难点在哪里

1.1 鲜奶订购和普通电商的本质区别

先把这个事情说透。很多同学一看到“订购系统”四个字，下意识就套用电商系统的思路：商品表、购物车、订单表、支付、发货。如果你真按这个套路去做鲜奶订购系统，做到一半就会发现哪里都不对劲。

鲜奶订购和普通电商最大的区别在于：普通电商卖的是“一次性的现货交易”，用户下单付款，商家发一个快递，订单就结束了。而鲜奶订购卖的是“周期性的履约服务”，用户今天下单买的是“未来一个月每天早上送一瓶250ml的鲜牛奶”，这意味着你的系统里每天都会产生新的履约动作，而不是商品发出去就完事。

再说得直白一点，鲜奶这个东西有三条硬约束：第一，保质期极短，巴氏杀菌奶冷藏状态下也就三到七天，库存不能按普通电商的“囤货”逻辑来做；第二，配送时效性强，订户要求的是早晨某个时间段内送达，晚半小时用户就不满意了；第三，变更频繁，用户出差三天、回老家一周、孩子放暑假暂停两个月，都是常态操作。这三个特点决定了系统的核心不是“卖货”，而是“履约计划管理”。

所以我在设计这个系统时，把绝大多数精力都放在了“订阅周期”和“配送日历”这两件事上，商品相关的模块反而是最常规的。你只要抓住了这个核心，后续所有功能都是顺水推舟。

1.2 系统角色与业务闭环

先理清楚系统里有哪几类角色，以及他们之间怎么协作，这一步别省，直接决定了你的表设计和接口划分。

这个系统我分成了三个端：

用户端，面向订奶的消费者，功能包括注册登录、浏览商品、选择配送周期下单、查看配送日历、暂停/恢复配送、余额充值和订单查询。用户最关心的两件事：我订的奶哪天送、哪天不送，以及我临时要暂停怎么操作。

奶站/配送员端，面向每天执行配送的工作人员，功能是查看当天的配送单，按线路装车，逐个订户标记送达或者未达，上报异常情况，比如用户不在家、门卫不让进、瓶子碎了等等。这个端不需要太复杂的交互，核心是“今日配送清单”准确无误。

后台管理端，面向系统运营人员，功能是商品上下架、价格调整、订阅订单管理、配送单查询、暂停/退款审核、每日配送数据统计。

整个业务闭环是这样的：用户下单付款 -> 系统根据起止日期生成整个订阅周期的配送计划 -> 每天凌晨定时任务捞取当天的配送计划项 -> 按奶站和线路归集生成配送单 -> 配送员执行配送并标记结果 -> 系统按天记账扣款 -> 月底生成对账单。

你可以看到，这个闭环里最核心的数据对象是“配送计划”，而不是“订单”。订单只是在用户下订的那一刻产生一次，而配送计划会伴随整个订阅周期每天运转。

1.3 技术选型的思路与取舍

技术栈选用的是常规的 SpringBoot 全家桶：SpringBoot 作为基础框架，MyBatis-Plus 作为数据访问层，MySQL 8.0 存储数据，Redis 做缓存和分布式锁，定时任务用 Spring 自带的 @Scheduled，登录态用 JWT，前端管理端用 Vue + ElementUI，用户端先做 H5 页面。

为什么这么选？两个原因。第一，这个业务的复杂度不在高并发，而在业务建模，SpringBoot 加 MyBatis-Plus 这种组合开发效率最高，单表 CRUD 几乎不用写 SQL，条件构造器可以直接拼查询，排查问题的时候打印出来的 SQL 也是直白的，不绕。第二，这个技术栈在行业内认知度最高，无论是作为毕业设计还是作为外包项目交付，接手的人都能很快看懂，这比炫技选个冷门框架要实在得多。

有人可能会问，为什么不用微服务架构？我的回答是杀鸡不用牛刀。一个鲜奶订购系统，即使做到一个城市几千个订户，日订单量也就是几千到上万级别，单体应用加一个合理的主从数据库完全能扛住。引入微服务意味着要处理注册中心、配置中心、网关、服务间调用、分布式事务，最后只会把这个项目的复杂度推向失控。

支付这块我也要提醒一句：如果只是做学习和演示，千万不要第一时间去对接真实的微信支付或支付宝，商户号申请、接口联调、资质审核会卡掉你一两周时间。我建议先做一个模拟支付模块，前端弹一个“支付成功”的交互，后端预留支付回调的入口，把整个业务流程跑通之后，再决定要不要替换成真实支付。

2. 数据库设计：把“订阅周期”建模清楚

2.1 用户、地址、商品的基础建模

基础表的建模相对常规，但有几个字段需要注意。

用户表的核心字段包括 id、手机号、昵称、密码、状态、余额。注意余额这里我建议用一个单独的账户表来存，而不是直接塞在用户表里，因为后续会有充值流水、扣款流水，账户和流水分开设计，财务对账会清晰很多。

地址表的字段要包含 id、用户id、收货人、联系电话、省市区、详细地址、默认标识、奶站id。这里我有一个自己的经验教训：奶站id一定要挂在地址表上，而不是挂在用户表上。因为同一个用户可能在公司订一份、在家里订一份，两个地址分属于不同奶站的配送范围，如果把奶站挂在用户表上，第二份订单就没办法正确路由到配送点了。

商品表里除了常规的 id、名称、分类、价格、规格、上下架状态，建议增加两个字段：一个是每日可售库存，一个是起订天数。每日可售库存表示这个商品今天最多能订多少份，鲜奶保质期短，按天控库存是基本操作；起订天数用于限制用户最少订多少天，常见的业务规则是七天起订，不然配送成本完全覆盖不了。

分类表就比较简单了，纯牛奶、酸牛奶、鲜牛奶、常温奶这么几类。商品和分类之间是多对一关系，外键不强制建立，但逻辑上要关联。

2.2 订阅订单：主从表结构设计

这是整个系统数据库设计里最关键的一个决策。订阅订单如果只设计一张主表，把用户、商品、起始日期、结束日期都存在一行里，那么“某一天到底要不要送奶”这个问题就无法独立表达。你不知道用户6月3号那天是正常配送还是已经暂停了，也不知道那天配送员到底送了没有。

所以我采用了“主子表”的结构。主表 subscribe_order 存订阅的总体信息，包括订单编号、用户id、地址id、商品id、商品名称、规格、单价、配送周期类型（每日送/隔日送）、开始日期、结束日期、总配送次数、订单总额、已付金额、订单状态、创建时间。

子表 subscribe_plan 存订阅周期展开后的每一天，也就是配送计划项，字段包括 id、订单id、计划配送日期、计划状态、关联的配送单id。这个子表是整个系统的灵魂，业务上所有需要“按天判断”的逻辑都要查这张表。

我把计划状态规划为这么几个值：pending 待配送、delivered 已送达、failed 配送失败、skipped 已跳过（也就是用户暂停）、canceled 已取消。每个状态代表这一天这个订户的实际履约情况。

为什么一定要拆成主子表？因为不同日期的计划项，在同一个时间点上的状态是完全不同的。比如今天是6月5号，6月5号的计划项可能已经被配送员标记为已送达，6月6号的计划项还是待配送，而6月10号的计划项已经被用户暂停了。如果你只靠一张主表，根本无法表达这种每天独立的履约状态。拆开后，每天的数据独立可查，暂停、恢复、补送这些操作也都变成了对具体某几行 plan 的简单状态更新。

创建订阅订单的时候，根据起止日期一次性生成整个周期内所有的 plan 记录。比如用户订了一个月，从6月1日到6月30日，每日配送，那就生成30条 plan。你不用担心数据量会爆炸，一个一万用户的系统，每人平均生成60条 plan，也就是60万行级别，MySQL 处理起来毫无压力，加上联合唯一索引和按日期查询，性能完全不是问题。

2.3 配送日历：暂停与恢复的核心建模

配送日历在界面上看起来是一个月视图，用户点击某几天然后选择“暂停”，系统就修改对应日期的配送计划。这个功能听起来简单，实现上有几个边界要处理好。

我单独设计了一张 pause_log 暂停记录表，字段包括 id、订单id、暂停开始日期、暂停结束日期、操作人、暂停原因、创建时间。这张表的作用是留痕，方便后台管理人员查看“这个订户为什么这段时间没送奶”，也方便月底结算时核对扣款明细。

暂停操作的业务规则有这么几条：第一，用户只能暂停“计划状态为待配送”的日期，已经生成配送单并且配送员已经开始执行的日期，不能再暂停，这一点非常关键；第二，暂停的最小单位是一天，用户不能说“我只停半天”；第三，暂停需要提前一定时间操作，我在系统里把截止时间设为前一天晚上8点，超过这个时间点，第二天的配送单可能已经生成，不能再改了。

恢复操作就是暂停的反向操作，把指定日期范围内状态为 skipped 的 plan 批量改回 pending。但要注意，只有“未来日期”的 skipped 才能恢复，已经过去的日期不能恢复，否则配送员那边会出现幽灵配送单，司机按地址找过去发现根本没有这一单。

这个建模方式的优势在于：它把暂停和恢复变成了对 plan 表的定点状态修改，逻辑非常直接，不容易出错。我见过有的系统用“单独一张暂停时间段表，业务查询时动态判断这个日期在不在暂停区间内”的建模方式，这种方式看似省了 plan 表的存储空间，但每次查询配送单都要做一次区间判断，SQL 写起来绕，出错概率大得多。相比之下，提前把周期展开成每一天的明细，然后把“暂停”落到具体行上，是牺牲了一点点存储换来了极大的逻辑简化。

3. 核心功能落地：从下单到配送单生成

3.1 订阅下单的接口流程

下单接口是整个业务链路的入口，我把它设计成 POST /api/subscribe/order，前端提交的参数包括商品id、地址id、开始日期、结束日期、配送周期类型，以及支付方式。

后端接收到请求之后，处理流程是这样的：

先做基础校验，包括商品是否处于上架状态、地址是否属于当前用户、开始日期是否早于明天、结束日期是否晚于开始日期、订购天数是否达到起订天数。

然后计算配送次数，每日配送的方式，配送次数就是结束日期减开始日期加一；隔日配送的方式，配送次数就是日期区间内每隔一天取一次的总数。这个计算在代码实现时要用循环遍历所有日期然后按周期过滤，不要用数学公式直接推，因为后续如果要支持“每周一三五送”这类复杂周期，公式法会变得难以维护，而遍历法只需要改一下过滤条件。

接着创建主订单记录，状态设为待支付，再批量生成 plan 明细，状态全部设为待配送。这两步必须放在同一个事务里，先插入主单拿到自增id，再批量插入 plan 记录，任何一个环节报错都要回滚，绝不允许出现“主单创建成功但 plan 只有一半”的脏数据。

最后发起支付。如果是模拟支付，就直接把主单状态更新为生效中，plan 保持待配送；如果是真实支付，需要先调起支付渠道生成预支付单，然后在回调里更新状态。我在系统里两种模式都预留了入口，通过配置项切换，调试阶段用模拟支付，上线前切到真实支付。

这里我想特别强调一个容易被忽视的点：plan 的生成逻辑不要写在 Service 里散着来，而是单独抽一个方法，输入订单和日期区间，输出配送日期列表。因为这个逻辑在下单的时候要用，后面管理端做补单、做批量导入、做测试数据生成的时候都要复用同一个方法，抽出来能避免各个调用方写出的日期规则不一致。

3.2 每日配送单生成的实现

配送单生成是这个系统里最具有“工程感”的一个功能。我定的规则是每天凌晨3点执行一次定时任务，把当天需要配送的所有商品按奶站分组，生成配送单。

生成逻辑的核心代码如下：

public void generateDailyDeliverySheet(LocalDate date) { // 1. 加分布式锁，防止多实例重复执行 String lockKey = "generate:delivery:" + date; boolean locked = redisLock.tryLock(lockKey, 60 * 1000); if (!locked) { return; } try { // 2. 查询当天所有待配送的 plan，且订阅订单处于生效状态 List<SubscribePlan> plans = planMapper.selectPendingPlans(date); if (CollectionUtils.isEmpty(plans)) { return; } // 3. 按奶站分组 Map<Long, List<SubscribePlan>> stationGroup = plans.stream() .collect(Collectors.groupingBy(plan -> plan.getStationId())); // 4. 每个奶站创建一张配送单头，明细插入配送明细表 for (Map.Entry<Long, List<SubscribePlan>> entry : stationGroup.entrySet()) { Long stationId = entry.getKey(); List<SubscribePlan> stationPlans = entry.getValue(); DeliverySheet sheet = new DeliverySheet(); sheet.setStationId(stationId); sheet.setDeliveryDate(date); deliverySheetMapper.insert(sheet); for (SubscribePlan plan : stationPlans) { DeliveryItem item = new DeliveryItem(); item.setSheetId(sheet.getId()); item.setPlanId(plan.getId()); item.setAddressId(plan.getAddressId()); item.setProductName(plan.getProductName()); item.setQuantity(plan.getQuantity()); deliveryItemMapper.insert(item); // 5. 回填 plan 的状态和 sheet 关联 plan.setSheetId(sheet.getId()); planMapper.updatePlanSheet(plan); } } // 6. 扣减当日可售库存 stockService.deductDailyStock(date, plans); } finally { redisLock.unlock(lockKey); } }

生成配送单时有几个细节要处理。第一，同一个订户同一天如果有多个不同商品，比如订了一瓶鲜奶再加一瓶酸奶，那么 plan 是两条，配送明细也是两条，但这两条要尽量排在相邻的位置，方便配送员取货。我的做法是在生成 item 的时候带上一个线路序号字段，按地址所在小区分组后依次编号。第二，已经生成过配送单的 plan 不能再次生成，这一点由数据库唯一索引和代码里的状态判断双重保障。第三，如果计划执行过程中发现有一部分 plan 因为数据异常无法生成，要有日志记录，不能静默失败。

配送员的端上展示逻辑简单很多：按配送单id查询明细，按线路序号排序，逐个标记送达或未达。标记送达的操作同时更新 plan 状态为 delivered，这个状态同步要保证，不然用户端看到“待配送”但是配送员已经送了，会产生客诉。

3.3 暂停与恢复接口的实现细节

暂停接口我设计为 POST /api/subscribe/pause，参数是订单id、暂停开始日期、暂停结束日期。进入接口之后，处理流程如下：

先校验订单属于当前登录用户，防止越权操作。然后校验时间参数，开始日期不早于明天，结束日期不晚于订阅结束日期，开始日期不晚于结束日期。最关键的一步是校验这些日期没有被生成过配送单，也就是 plan 里 sheet_id 字段为空，如果某个日期已经有配送单，说明配送员可能已经看到了这个单子，不能再暂停。

校验通过后，批量更新 plan 状态为 skipped，并插入一条 pause_log 记录。整个操作在一个事务里完成。

恢复接口的逻辑结构类似，但有一个额外的限制：只能恢复未来的 skipped 日期，已经过去的日期保持 skipped 不变。因为过去的那天配送员已经按照暂停安排出车了，恢复没有任何意义。

还有一个容易被忽略的点：用户的暂停操作对余额结算的影响。我在系统里采用的规则是“暂停期间不配送、不扣款”，而不是“暂停期间仍然扣款然后退款”。前者简单直接，plan 状态为 skipped 的日期在月底结算时自动跳过；后者涉及退款单、原路退回、财务审批，复杂度上升一个量级。对于学习项目或者业务初期，我强烈建议用前者，规则简单，用户也容易理解。

4. 缓存、定时任务与并发控制

4.1 Redis 在系统里的具体定位

Redis 在这个系统里不是摆设，但也别把它用滥了。我的策略是三个场景必须用，其他场景一律不用。

第一个场景是分布式锁。定时任务生成配送单的时候，如果是多实例部署，两个实例同时扫描到当天有 pending 状态的 plan，就会重复生成配送单，这是最典型的需要加锁的场景。我用 Redis 的 SETNX 命令实现了一把简单的锁，key 包含日期，value 是实例标识，过期时间设30秒，任务执行完主动释放。

第二个场景是当日配送单的缓存。配送员端打开首页要看今天自己负责的配送单，这个接口的查询 SQL 涉及配送单头、明细、地址、商品多张表联查，如果每个配送员每次进页面都打到数据库，高峰期数据库压力会很大。我的做法是配送单生成后，把整理好的配送明细结构序列化后存入 Redis，key 格式为 delivery:sheet:{stationId}:{date}，配送员查询时先读缓存，缓存没有再去数据库查并回填。

第三个场景是热点商品信息缓存。商品详情和价格在用户端的访问量比较高，变化频率低，缓存到 Redis 可以减轻数据库查询压力，同时做一版简单的缓存一致性处理：后台修改商品信息时，先更新数据库，再删除缓存。

这里有一个我踩过的坑：用户余额的扣减绝对不能依赖 Redis 里的余额数据。有的系统为了追求响应速度，把余额也缓存到 Redis，扣款时先改 Redis 再异步同步数据库，一旦 Redis 数据丢失或者同步失败，用户余额对不上，就是巨大的财务事故。余额数据只以数据库为准，Redis 最多做展示层面的缓存，且缓存超时时间设置得很短。

4.2 定时任务框架：单机与分布式的选择

定时任务在 SpringBoot 里最轻量的实现方式就是 @Scheduled 注解，对单体应用来说，在启动类上加一个 @EnableScheduling，然后在方法上配置 cron 表达式，一行代码就能搞定定时逻辑。

我在这个系统里用了三个定时任务。第一个是凌晨3点生成当日配送单，核心任务，错不得。第二个是早晨6点半发送配送提醒通知，给当天有配送计划的用户发一条模板消息。第三个是每天晚上10点做一次数据巡检，把 pending 状态但已经超过当天日期的异常 plan 找出来，标记为异常，并通知运营人员检查。

但如果你要部署多个实例，用 @Scheduled 就会有问题：每个实例都会执行定时任务，三个实例就是三倍重复执行。这种情况下有两个解决方案。第一个方案是继续用 @Scheduled 但配合 Redis 分布式锁，只有抢到锁的实例才执行，优点是改动最小，缺点是没有任务调度平台的可视化和失败重试机制。第二个方案是引入 XXL-Job，它有独立的调度中心，任务配置在页面上做，自带分片广播、失败重试、执行日志，算是行业内的标准方案。

我的建议是：如果这个项目是教学演示用，用 @Scheduled 加 Redis 锁就够了，代码简单，便于大家理解核心逻辑；如果是公司里的真实生产项目，直接上 XXL-Job，省得后期又要迁移。

4.3 扣款与状态更新的并发安全

余额扣款是一个典型的并发操作场景。用户同时发起两笔支付，或者定时任务在扣当天的奶款，用户又在手动充值，如果处理不好，就会出现余额扣成负数或者扣款记录不一致的问题。

我用的是数据库层面的乐观扣减方案，核心 SQL 如下：

UPDATE account SET balance = balance - #{amount} WHERE user_id = #{userId} AND balance >= #{amount}

这条 SQL 的关键在于 where 条件里的 balance >= amount，它保证了如果余额不足，影响行数会是0，代码里通过判断执行结果来决定继续还是中断事务，从而避免余额被扣成负数。

在这个基础上，账户流水表每一笔记录都要有唯一的业务单号，比如订单号或者配送单号，加唯一索引防止同一条扣款被重复执行。这在支付回调场景里尤其重要，微信支付的回调有可能会重复推送，第一次回调成功更新了订单状态，第二次回调如果没做幂等处理，就会把同一笔订单扣两次款。

关于事务边界，我的原则是：扣款和对应的订单状态更新必须在同一个事务里，用 @Transactional 注解包住，先扣款，后更新状态，任何一个失败就整体回滚。这样能保证“钱扣了但订单状态还是待支付”这类脏状态永远不会出现。

5. 踩坑实录与问题排查

5.1 配送单重复生成

这个坑是我在做定时任务时遇到的第一道坎。现象是某一天生成配送单后，发现同一个订户的同一个计划项在配送明细里出现了两条，配送员按着两条明细装了两瓶奶，实际订户只要一瓶。

排查下来原因有两个：一是当时测试环境部署了两个实例，又没有加分布式锁，两个实例在同一时刻扫描到了同一批 pending 的 plan，各自执行了一遍生成逻辑；二是定时任务框架在执行失败有重试机制时，没有做幂等处理，重试又跑了一遍。

现在的解决办法是三重保障：第一，Redis 分布式锁，保证同一时刻只有一个实例在执行生成逻辑；第二，数据库在配送明细表上加了唯一索引，联合字段是 sheet_id 和 plan_id，真出现重复插入时直接被数据库拒掉；第三，生成前的代码逻辑里做一次检查，plan 的 sheet_id 如果不为空就直接跳过，不再生成。三层下来，这个问题基本可以杜绝。

5.2 暂停被定时任务覆盖

这个Bug 比较隐蔽，也更值得写出来。现象是用户在 app 上暂停了第二天的配送，操作成功也提示了“已暂停”，但第二天配送单里还是有他的货。

排查发现，问题出在数据可见性上。定时任务启动时扫描了一批 plan，这批 plan 的状态当时还是 pending，其中就包括用户刚暂停的那一条。用户提交暂停操作更新了 plan 状态为 skipped，但定时任务进程里已经驻留了这条 plan 的旧数据快照，它在生成配送单时用的是自己内存里的旧数据，没有重新查库，所以就把已经暂停的计划项也生成了配送单。

更正后的逻辑做了两处调整：一是在生成配送单的最后一步，从数据库重新按主键查询 plan 的最新状态，如果发现已经被改成 skipped，就跳过这一条；二是暂停接口增加了时间判断，当天的配送单已经生成的情况下，不允许暂停，直接给用户提示“今日配送单已生成，如需暂停请从明天开始”。

5.3 跨日订单与时区问题

有一次用户反馈说，他晚上11点半下单选择“明天开始配送”，结果第二天的配送单里没有他的奶。一开始我以为是定时任务的扫描逻辑漏了数据，查了半天发现是日期边界的问题。

这个订单的开始日期存的是 LocalDate，逻辑上“明天”应该是用户所在时区的明天，但定时任务运行时区是服务器时区。如果服务器时区配置成 UTC 而不是东八区，服务器上的“今天”和用户的“今天”就不是同一天，datetime 类型的当前时间转换出来的日期就差了一天。

现在的规范是：所有跟配送日期相关的字段一律使用 LocalDate 类型，不存 datetime，存 datetime 的一律显式指定东八区时区。下单接口生成开始日期时，用 LocalDate.now() 获取当前日期再加一天，不允许用服务器时间的字符串截取，从根本上杜绝跨日错乱。

5.4 越权访问的接口漏洞

越权问题在联调阶段才暴露出来。测试人员在暂停接口上传了一个不属于自己账户的订单id，结果直接把别的订户的配送计划改了，幸好是测试环境，要是生产环境就是一起严重的数据安全事件。

排查下来发现，接口里只校验了参数合法性，没有校验订单归属。处理方式是在 Service 层统一加一道归属校验：凡是涉及用户数据的操作，先用当前登录用户的 id 去查数据归属，查不到或者归属不一致就抛业务异常。这一步不能放在 Controller 层，因为 Controller 可能被多个调用方复用时遗漏；建议在 Service 层做一个统一的 BaseService 方法，任何订单、地址、账户操作都必须先过这道校验。

我建议在测试阶段专门写几个越权测试用例，把“A用户操作B用户订单”的各个场景都覆盖到，这类问题越早发现越好修，上线之后再发现就是事故。

6. 真实跑起来的效果与扩展建议

6.1 用户端与管理端功能清单

系统完整跑通之后，用户端的核心页面包括：首页商品列表、商品详情页、下单页、配送日历、订阅列表、订单详情、余额充值、个人中心。配送日历是用户端交互最重的页面，一个月的日期网格里，灰色表示暂停，绿色表示待配送，蓝色表示已送达，用户点击任意未来日期就能发起暂停或恢复。

管理端按模块看更清晰一些，我整理成一张表：

做演示的时候，最怕的是系统里没有数据。我的建议是单独写一个测试数据生成器，模拟几百个用户、几十个商品，自动生成未来30天的 plan，并随机打上部分暂停已送达的状态。这样演示的时候从用户端和管理端看都有完整的数据，不会出现“定了一个订单，配送日历却是空的”这种尴尬场景。

6.2 扩展方向与个人心得

这个系统后续可以扩展的方向还是很多的。比如把用户端从 H5 升级为微信小程序，推送给用户的模板消息能直接点到配送日历；配送员端做一个独立的微信小程序，扫码签收加拍照留证，异常件拍照上传，运营后台可以直接看到配送现场的证据。还有按周/按月的财务结算报表、按小区聚类优化配送线路、每日鲜奶库存预警和临期处理建议，这些都是业务需求自然延伸出来的模块。

从我个人的经验看，做这种“实体业务 + 管理系统”的项目，最大的收获往往不在技术本身，而在于把一个真实世界的业务规则转换成数据模型的能力。你把配送计划表设计明白了，暂停规则想清楚了，后面的接口开发就是体力活；反过来，如果一上来就直接写 Controller，后面被业务规则反复打回改表结构，那才是真正的噩梦。

最后再分享一个小技巧：这个项目作为教学演示时，余额支付和模拟支付已经足够撑起整个业务闭环，可以先把侧重点放在订购流程、配送日历、定时任务这些核心逻辑上，不要被支付认证、资质审核这类外部依赖拖住进度。等核心流程都验证没问题，再考虑接真实第三方支付和真实短信服务，一次只引入一个外部依赖，排查问题的时候也能更从容。