SpringBoot私房菜上门定制系统：订单并发控制与状态机设计

1. 这个系统到底在解决什么

1.1 私房菜上门定制：被"信息差"卡住的场景

先说个我自己的经历。有段时间我想在家里招待几个老朋友，想去外面请个厨师上门做顿家常菜。结果打开各类App，要么是成品外卖，要么是那种高端到离谱的商务宴请套餐，中间的"私房菜上门定制"这个需求，几乎是空白的。要么靠熟人介绍，要么就只能在社群里碰运气，价格、口碑、师傅的擅长菜系完全说不清。

私房菜上门定制系统和普通外卖系统最大的区别在于，外卖是"人找菜"，把人叫到店或把成品送过来；而这个是"菜找人"，厨师带着食材、手艺和工具直接到客户家里完成整个烹饪过程。这就带来一个完全不一样的问题栈：厨师的时间档期管理、上门服务范围、私人定制需求的录入、食材的确认、和传统点餐逻辑完全不同的计费方式，以及一个跨线上线下的履约链路。

我做的这套系统，本质上是把"家庭场景"和"专业厨师"之间那条低效的信息通道产品化。核心用户有两类，一类是家庭客户，希望在家办私宴、纪念日、周末聚会；另一类是独立厨师和私厨小团队，有手艺但缺少稳定的获客渠道。再加上平台运营方需要审核厨师、看数据、结算佣金，整个系统就至少要面对三种角色：普通用户、厨师、平台管理员。

1.2 核心角色与三条主链路

做设计之前，我先把业务链路捋了一遍，最后收敛成三条主链路。

第一条，用户侧链路：浏览厨师主页和能力展示 → 选择服务套餐或提交定制需求 → 选定上门时间 → 支付定金或全款 → 等待厨师确认 → 厨师上门服务 → 服务完成确认 → 评价。

第二条，厨师侧链路：注册入驻 → 提交资料审核 → 维护个人简介、擅长菜系、私房菜单和档期表 → 收到订单提醒 → 接单或拒绝 → 上门履约 → 完成订单标签 → 提现结算。

第三条，平台侧链路：厨师入驻审核 → 菜品和定价审核 → 订单状态监督 → 售后纠纷处理 → 佣金统计和排行。

这三条链路如果画成代码里的领域模型，其实就是三套核心域对象：用户域、厨师域、订单域。而订单域是中间最重的部分，因为它把用户的时间选择、厨师的时间确认、菜品明细、服务地址、价格计算全部串在了一起。系统设计时，我的第一原则就是先抓订单，订单想清楚了，其他模块都是围绕着它长出来的。

提示：做这类O2O定制类系统，千万不要一上来就画十几个表。先把"一个订单从创建到完成的完整生命周期"走通，再往两边延伸，效率会高很多。

2. 技术选型：为什么是SpringBoot

2.1 从项目处境看框架选型

很多技术人在写"基于SpringBoot的系统"时，对选型理由都是一笔带过，好像SpringBoot是默认答案。但作为实际要落地、要答辩、要演示的项目，选型理由必须能回答三个问题：团队/个人的技术栈熟不熟、业务场景匹配不匹配、后续维护和扩展成本高不高。

我选SpringBoot的理由很简单：这个项目处在"单机起步、面向中小规模、需要快速迭代"的阶段。私房菜上门定制不是一个高并发海量数据的场景，至少初期不是。它更像一个典型的业务管理系统加轻量级C端接口，核心复杂度在业务规则和状态流转上，而不在大流量架构。SpringBoot在这种场景下几乎是把正确的事情都做对了：内嵌容器免部署、自动配置省去一大批XML、Starter体系把Redis、安全认证、数据库访问的整合成本压到极低。

对比一下，如果用SpringMVC加一堆XML，项目一半时间会花在配置和环境搭建上；如果用微服务那套，分布式事务、服务发现、配置中心这些重量级组件对这个体量的项目纯属负担。这中间的分寸，就是SpringBoot：它单体能跑得很舒服，未来真要拆微服务，也能按模块平滑拆出去。

2.2 技术栈全景与核心依赖

整个系统的核心技术栈我给一个清单，都是这个场景下比较稳妥的组合。

这整套组合下来，构建成本和排错成本都很低。尤其是MyBatis-Plus，对这个项目的帮助很大，因为订单、档期、菜品这些表都有大量条件组合查询，有了条件构造器，很多动态SQL就不用手工拼接了。

2.3 整体分层与模块划分

代码结构上，我按经典的Controller-Service-Mapper三层走，但在Service层内部又单独划了几个领域服务，避免所有业务逻辑堆在订单Service里变成一个"上帝类"。

• controller：只做参数校验、结果包装、异常转换
• service：按用户、厨师、订单、档期、菜品、支付、统计拆成独立领域服务
• mapper：数据访问层，复杂统计走XML
• dto/vo：入参对象和出参对象分离
• common：统一返回体、异常体系、常量、枚举
• config：安全配置、Redis配置、跨域配置等
• util：时间处理、订单号生成等工具类

模块划分上，我没有用多Module工程，因为单Module在这个体量下维护起来更直接。但代码包结构是按模块边界分的，这比物理拆工程更符合实际开发节奏。有人会问，为什么不直接用微服务？我的看法是，业务还没复杂到需要独立部署和独立数据库的程度，硬拆微服务只会让本地起个服务都要开五个应用，纯给自己添堵。

3. 数据库设计：一张订单背后的表关系

3.1 核心表清单

这个系统的表不算多，但每张表的职责要清晰。我最终保留了以下核心表。

• user_account：平台账号表，包含手机号、加密密码、角色标识
• cook_profile：厨师扩展表，关联用户表，存真实姓名、个人简介、擅长菜系、服务区域、审核状态
• dish：菜品表，关联厨师，存菜品名、图片、描述、价格、分类、状态
• custom_demand：定制需求表，存用户填写的特殊要求，比如忌口、想吃的菜系、是否自备食材
• schedule_slot：厨师档期表，存可服务的时间段，是并发控制的重点
• reservation_order：订单主表，存订单号、买卖双方、上门时间、地址、总额、状态
• order_item：订单明细表，存订单下的菜品快照
• payment_record：支付流水表，存支付单号、金额、渠道、回调状态
• review：评价表，关联订单，存评分和文字评价

这十张表基本就能把主链路跑通。用户收藏、优惠券、厨师提现这些属于可扩展功能，我放在二期设计里，不在核心链路中占优先级。

3.2 关键表DDL节选

给几张关键表的DDL做个节选，这是实际实践时的库表基础。

CREATE TABLE schedule_slot ( id BIGINT PRIMARY KEY AUTO_INCREMENT, cook_id BIGINT NOT NULL COMMENT '厨师ID', slot_date DATE NOT NULL COMMENT '档期日期', start_time DATETIME NOT NULL COMMENT '可服务开始时间', end_time DATETIME NOT NULL COMMENT '可服务结束时间', status TINYINT NOT NULL DEFAULT 0 COMMENT '0-可预约 1-已占用 2-停用', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_cook_slot (cook_id, start_time), KEY idx_date_status (slot_date, status) ) COMMENT '厨师档期表'; CREATE TABLE reservation_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '订单号', user_id BIGINT NOT NULL, cook_id BIGINT NOT NULL, slot_id BIGINT NOT NULL COMMENT '占用的档期ID', service_address VARCHAR(255) NOT NULL, service_time DATETIME NOT NULL COMMENT '上门服务时间', total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0-待付款 1-待接单 2-进行中 3-待验收 4-已完成 5-已取消 6-售后中', custom_requirement TEXT COMMENT '定制需求描述', remark VARCHAR(255), create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_user_status (user_id, status), KEY idx_cook_status (cook_id, status) ) COMMENT '订单主表';

这里有两个细节值得说明。第一，schedule_slot里做了(cook_id, start_time)的唯一索引，这是防并发超卖的第一道物理约束。第二，reservation_order里冗余了service_time，没有从档期表去关联查。因为订单的时间一旦生成就不应该被档期表的后续修改影响，这是一种快照思想。

3.3 为什么订单要独立明细表

有人可能会说，私房菜定制很多是"需求描述"式的，不像外卖那样有固定菜品，有必要单独拆order_item吗？

我觉得非常有必要。首先，虽然一部分用户直接选择厨师现有的私房菜套餐，但另一部分用户会提交"帮我配一桌八人的家宴，要有两个凉菜两个硬菜一个汤"这种需求，平台需要把这种意向转化为具体的菜品清单，哪怕这个清单是厨师接单后补充的，也需要有地方存。其次，套餐和单点会混合成"半定制"订单，比如用户选了一个套餐又额外加了一道菜。没有明细表，只能把价格塞进一个字段里，后续退款、售后、统计都很难受。

订单明细表里的dish_name和price我用的是快照字段，不关联菜品表。原因很简单，厨师改价或下架菜品是常态，但历史订单里的交易金额必须保持稳定。所有涉及金额的模块，我统一遵循"落库即定格"的原则，查询时永不实时回源菜品表。

4. 核心功能实现与难点处理

4.1 用户定制下单：需求描述+传统菜品的组合

定制下单是这个系统的门面功能，我把它设计成两种模式。

一个是"选品下单"。用户进入厨师主页，浏览已发布的可选菜品，像点外卖一样把感兴趣的菜加入清单，然后选择上门时间段。这种模式的订单明细是确定的，可以直接算价格。

另一个是"说需求下单"。用户不具体选菜，而是填写一句话需求，"八人聚餐，两荤两素一汤，口味清淡，自备食材"，再选时间段。这种模式下，厨师接单之后可以补充菜品明细、确认最终报价，用户确认后才算锁单。

两种模式在数据模型上并不矛盾，核心订单表中都有custom_requirement字段，order_item可空。区别在下单之后的校验逻辑。选品下单走常规的价格计算和库存校验；说需求下单则一笔带过，关键动作是通知厨师来看需求，厨师报价之后，用户有一个确认动作。

这里有一个经验：不要试图用优惠券、会员等级等规则把下单流程塞得太满，尤其对这种定制类需求，用户的核心诉求是"把需求准确传达出去"，而不是像抢券那样追求秒级下单。所以我的下单接口设计得很轻，参数名直白，后台装配逻辑清晰即可。

4.2 档期预约与并发冲突（核心难点）

私房菜上门和堂食最大的区别，是每一单都要占据厨师的一段完整时间。所以档期冲突处理比库存扣减更微妙，因为它不是简单地减一个数字，而是要保证同一时间段不会被两个订单占用。

我的方案是"预生成档期 + 唯一索引 + 乐观锁 + Redis预占"四层防线。

第一层，档期预生成。厨师开通服务时，按每周规则批量生成固定时间段，比如周一到周五晚上、周六周日全天。系统生成粒度是30分钟，这样既能满足一般家庭用餐需要，又不至于让档期表无限膨胀。

第二层，物理唯一约束。同一位厨师的start_time唯一，数据库直接拒绝两条重复记录，这是兜底。

第三层，乐观锁。档期表加了version字段，用户在支付或确认订单时更新档期状态用UPDATE ... WHERE id = ? AND version = ?，更新影响行数为0则说明已被抢走。

第四层，Redis预占。订单创建前，先往Redis里写一个短TTL的锁标记，比如cook:slot:lock:{cookId}:{startTime}，设置过期时间3分钟。这样用户在填订单信息的过程中，这个时间段对其他用户是不可见的，防止两个用户同时卡在支付页里，最后只有一个人能成功。

这块实际踩坑不少，我放到后面的常见问题部分详细讲，这里先记住一个结论：光靠数据库唯一索引不够，因为用户体验不好，用户填了一堆信息最后下单失败会很恼火；光靠Redis锁也不够，因为极端情况Redis重启或者锁过期，还是要靠数据库兜底。多层级联才是正道。

4.3 订单状态机的设计与流转

订单系统最忌讳的就是状态满天飞，if里到处改状态。我的做法是先定义一个订单状态枚举，把每条状态变更的前置条件和后置动作都收拢在一张流转表里。

主要状态就六种：待付款、待接单、服务中、待验收、已完成、已取消，外加一个售后中。

• 用户创建选品订单后，订单处于待付款。支付成功进入待接单。
• 说需求订单从待接单开始，但多一层"厨师待报价"的内部子状态。
• 厨师接单后，订单进入待服务或服务中。
• 服务完成后，厨师发起完成操作，订单进入待验收。
• 用户确认验收或超时自动验收，订单变为已完成。
• 任何一个待支付状态超过30分钟未支付，自动取消，释放档期。

我把这个状态机的流转逻辑做成了OrderStatusHandler，每次状态变更都会校验前置状态，防止从已完成直接跳跃到已取消这种事发生。

这里有个容易被忽略的细节：状态变更记录。我额外建了一张order_status_log表，记录每个订单的状态变更历史。最初我觉得这个表是多余的，后来有用户投诉"我明明付款了怎么显示未支付"，全靠查这张日志表定位到是支付回调丢失的问题。从那之后，我建议每一个订单类系统都留一张状态日志表，成本很低，排查问题收益极高。

4.4 支付对接的抽象设计

支付环节我特别想多说一句。很多做SpringBoot练手项目的人，喜欢直接用某个支付SDK的类，然后整个项目到处引用。看起来很顺利，但一旦要换支付渠道或者接入沙箱和正式环境切换，就会变成一场灾难。

我在设计时就给支付定义了一个统一接口。

public interface PaymentGateway { String pay(PayRequest request); PayResult parseNotify(String notifyData); boolean refund(RefundRequest request); }

微信支付沙箱和支付宝沙箱分别实现这个接口，通过一个工厂类根据订单里的支付渠道字段创建对应实现。这样业务Service里永远只面向接口编程，支付渠道的细节被完全隔离。

这个抽象也极大降低了联调成本。开发时用沙箱实现跑通流程，切换正式环境时只需要替换注册的Bean实现，业务代码一行不用动。对于私房菜这种C端小额高频支付的场景，我认为这是一个性价比极高的设计。

5. 代码落地：几个可以直接抄的模块

5.1 档期时间冲突查询SQL

档期冲突的查询，要能回答"某厨师在某个时间范围内是否有空闲档期"。因为在页面上要展示可预约时间段，所以查询逻辑需要支持范围条件。

SELECT id, cook_id, start_time, end_time, status FROM schedule_slot WHERE cook_id = #{cookId} AND start_time < #{endTime} AND end_time > #{startTime} AND status = 0 ORDER BY start_time;

这段SQL看起来简单，但有一个关键点：判断两个时间段是否重叠，条件是start_time < 传入结束时间且end_time > 传入开始时间。我第一次写的时候用的是BETWEEN，结果正好卡在边界情况的档期就被漏掉了，排查了很久。

光有这个查询还不够，真正的预约操作是给指定ID的档期做条件更新。MyBatis-Plus的写法比较简洁：

boolean success = scheduleSlotMapper.update( null, new LambdaUpdateWrapper<ScheduleSlot>() .eq(ScheduleSlot::getId, slotId) .eq(ScheduleSlot::getStatus, SlotStatus.AVAILABLE.getCode()) .eq(ScheduleSlot::getVersion, slot.getVersion()) .set(ScheduleSlot::getStatus, SlotStatus.BOOKED.getCode()) .set(ScheduleSlot::getVersion, slot.getVersion() + 1) ) == 1;

影响行数为1表示这个档期没被别人抢走，后续可以继续创建订单；为0则告诉用户"这个时间刚刚被人约走了"。整个过程对普通业务开发来说足够简单可靠。

5.2 下单核心Service

下单Service是整个项目被问得最多的一段代码，我在这里贴一个简化但完整逻辑可跑通的版本。

@Service @RequiredArgsConstructor public class OrderService { private final ReservationOrderMapper orderMapper; private final ScheduleSlotMapper slotMapper; private final StringRedisTemplate redisTemplate; @Transactional(rollbackFor = Exception.class) public PlaceOrderResult placeOrder(PlaceOrderCommand cmd) { // 1. Redis预占，防止用户表单填写期间档期被抢 String lockKey = String.format("cook:slot:lock:%d:%s", cmd.getCookId(), cmd.formatStartTime()); boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofMinutes(3)); if (!locked) { throw new BizException(ErrorCode.SLOT_BEING_BOOKED); } // 2. 查询档期并做乐观锁更新 ScheduleSlot slot = slotMapper.selectById(cmd.getSlotId()); if (slot == null || !slot.isAvailable()) { throw new BizException(ErrorCode.SLOT_NOT_AVAILABLE); } boolean updateSuccess = slotMapper.update(null, new LambdaUpdateWrapper<ScheduleSlot>() .eq(ScheduleSlot::getId, slot.getId()) .eq(ScheduleSlot::getStatus, SlotStatus.AVAILABLE.getCode()) .eq(ScheduleSlot::getVersion, slot.getVersion()) .set(ScheduleSlot::getStatus, SlotStatus.BOOKED.getCode()) .set(ScheduleSlot::getVersion, slot.getVersion() + 1) ) == 1; if (!updateSuccess) { throw new BizException(ErrorCode.SLOT_JUST_SOLD_OUT); } // 3. 写入订单主表 String orderNo = generateOrderNo(); ReservationOrder order = ReservationOrder.builder() .orderNo(orderNo) .userId(cmd.getUserId()) .cookId(cmd.getCookId()) .slotId(slot.getId()) .serviceAddress(cmd.getServiceAddress()) .serviceTime(cmd.getServiceTime()) .totalAmount(cmd.getTotalAmount()) .customRequirement(cmd.getCustomRequirement()) .status(OrderStatus.PENDING_PAYMENT.getCode()) .build(); orderMapper.insert(order); // 4. 如果选择了固定菜品，写明细 if (CollectionUtils.isNotEmpty(cmd.getDishIds())) { List<OrderItem> items = buildOrderItems(cmd.getDishIds(), order.getId()); orderItemMapper.insertBatchSomeColumn(items); } // 5. 返回订单号和待支付金额 return new PlaceOrderResult(orderNo, cmd.getTotalAmount()); } }

这段代码的核心思想是"先锁档期，再落订单"，顺序不能反。如果先写订单后锁档期，会出现订单已经有了但档期更新失败的情况，虽然事务能回滚，但要回滚逻辑更复杂且容易漏。

事务方法内部Redis锁的释放问题也要注意。我这里的Redis锁TTL是3分钟，而事务提交一般毫秒级完成，所以正常情况下锁会在事务提交后继续占着，防止用户选完菜还没支付期间档期被别人看到。这时候如果用户不支付，锁过期后档期重新开放，算是一种软释放。这比在事务方法里手动删锁要安全，因为手动删锁如果发生在事务提交前，会出现并发窗口。

5.3 接单与状态校验

厨师的接单操作，核心是状态校验。我的思路是，接单动作必须满足三个前置条件：订单存在、订单处于待接单状态、下单厨师与当前登录厨师一致。

public void acceptOrder(Long orderId, Long currentCookId) { ReservationOrder order = orderMapper.selectById(orderId); if (order == null) { throw new BizException(ErrorCode.ORDER_NOT_FOUND); } if (!order.getCookId().equals(currentCookId)) { throw new BizException(ErrorCode.NOT_YOUR_ORDER); } if (order.getStatus() != OrderStatus.PENDING_ACCEPT.getCode()) { throw new BizException(ErrorCode.STATUS_INVALID); } ReservationOrder update = new ReservationOrder(); update.setId(orderId); update.setStatus(OrderStatus.IN_PROGRESS.getCode()); update.setAcceptTime(LocalDateTime.now()); orderMapper.updateById(update); orderStatusLogService.record(orderId, order.getStatus(), OrderStatus.IN_PROGRESS.getCode(), "厨师接单"); }

有人可能觉得这种简单查询更新太繁琐，但订单类的数据必须保守。因为每个状态变更都涉及下游动作，比如厨师接单后要通知用户、要锁定档期、可能还要扣除一次短信通知次数。把这些动作的触发点放在一个显式的方法里，比在Mapper层做隐式联动要可控得多。

厨房接单后的通知，我用的是Spring的@Async事件监听器，发一个OrderAcceptedEvent出来，短信服务和站内信服务分别监听。这样接单主流程不受短信通道延迟的影响，用户也能立刻在订单列表看到状态变化。如果短信发送失败，事件监听器里有重试组件，最多重试三次。

6. 常见问题与排查技巧实录

6.1 并发下单如何把档期"卖了两遍"

这是这个项目里出现过的、印象最深的一个线上问题。

现象很简单：一场爬虫测试模拟了20个用户同时预约同一厨师的同一时间段，数据库里竟然生成了7个待付款订单，全部指向同一个档期。

排查过程先看Redis锁，锁正常；再看乐观锁SQL，更新条件带了version，理论上只能有一个成功。但问题出在并发执行的顺序上：多个线程同时select到同一个旧version，确实只有一个线程update能成功，其他线程应该报错。而实际是，事务A更新成功后事务尚未提交，事务B在它提交之前执行了select又拿到旧版本，但数据库的REPEATABLE READ隔离级别下，update语句是当前读，会读到事务A的未提交更新吗？在MySQL默认的InnoDB隔离级别下，不会。

可是我们用的MyBatis-Plus更新逻辑执行成功了？后来发现问题出在没有在update上真正开启事务，或者更准确地说是，并发时有些请求走了缓存，从Redis读到了档期状态还是"可预约"就直接放过去了。最终修法是三层联动全部串起来，且不能只查缓存不查库。现在写更新时，一定是先查库里的最新版本，再执行带版本条件的更新，不能依赖缓存里的旧状态做判断。

这个案例给我的教训是：像"库存扣减"这一类操作，缓存可以做预占和提示，但最终裁决必须交给数据库。Redis适合挡流量，不适合做唯一事实源。

6.2 事务不回滚的几种坑

有一次联调，测试反馈：下单接口偶尔会生成空明细订单，也就是订单主表有记录，详情列表却是空的。

查代码发现下单Service的确加了@Transactional，但问题出在一个常见陷阱上：事务方法是自调用的。当时写了一个内部私有方法处理明细插入，然后被下单方法直接this.call()调用，Spring的AOP代理没有拦截自调用，等于事务根本没有跨到那个方法，明细插入的异常被方法内部捕获吞掉了，于是主订单照常提交。

修法很简单，把自调用改成注入自己或把逻辑拆到另一个Service。类似的问题还出现在异步事件通知里，@Async方法如果被同一类内部调用，一样不会生效。排查这类问题最快的办法，是在日志里观察事务管理器打印的"Creating new transaction"日志，没有日志说明事务根本没开起来。

6.3 时间格式化与时区问题

私房菜订单对时间敏感，按时上门是核心体验，所以时间问题不能含糊。

开发初期，我在接口返回的LocalDateTime没有统一格式，前端拿到的是带T的毫秒串，显示得很不友好。后来全局配置了Jackson的LocalDateTime序列化格式，统一为yyyy-MM-dd HH:mm:ss。

还有一个坑是服务器时区。如果线上服务器是UTC，数据库是本地时区，用户在北京时间10点下的订单，服务端读取时间会自动偏移8小时。我最终在数据库连接串上明确指定serverTimezone=Asia/Shanghai，SpringBoot配置里也设置了spring.jackson.time-zone=GMT+8，这样三层时区全部对齐。

建议做任何订单系统的人，从第一天就统一用LocalDateTime，别用Date，也别在数据库里存varchar格式的时间。前者只有时区转换的问题，后者连计算时间差都成噩梦。

6.4 状态日志的重要性

再强调一次状态日志表的价值。有一次用户说"我明明已经付款了，但是页面显示待付款，钱也没退"。我就去查订单状态日志和支付流水，发现支付回调确实发生过，但因为回调处理逻辑抛了一个校验异常，事务回滚，把状态更新也一起回滚了。而用户那边微信已经扣款成功，于是形成"钱扣了，单没付"的中间状态。

如果当时没有状态日志表，光看订单表是看不到任何痕迹的。有了日志，就能快速定位到"回调已到达但处理失败"这个环节，再针对回调幂等和异常兜底去做修复。现在我的回调处理逻辑里，记录支付流水和更新订单状态分开了，即使某一步失败，另一个通过补偿任务也能处理。

7. 实操心得与后续扩展

整套系统做完，我最想分享的一个体会是：这类定制O2O系统的复杂度，不在并发量，而在业务状态的完整性。一个厨师上门做菜，从用户预约到最终验收，中间有太多"线下动作"需要线上状态去承接。任何一个环节状态没卡住，最后的结果就是线下扯皮、线上查不清。所以代码里宁可多写几个枚举、多写几行状态校验，也不要在状态管理上偷懒。

另外一个体会是关于演示和答辩的。做这类系统时，技术点一定要有一个"最能打"的亮点。我的项目里这个亮点就是档期并发预约的四层防护设计，围绕它既讲清楚了数据库并发控制，又讲清楚了缓存与数据库的一致性，还联系到了实际线上问题。建议做类似"XX系统的设计与实现"项目时，都挑一个这样的核心难点深挖，比平铺直叙十个功能点更有说服力。

这套系统的扩展空间其实很大。现在只是完成了订单主链路，后续可以往这几个方向走：一是给厨师加上距离和区域匹配，让服务范围不是手动勾选，而是通过地理位置计算；二是增加用户的私人食谱收藏和常点菜单，提升复购效率；三是做一个类似"周末家庭宴席"的主题推荐页面，把高转化场景前置。另外，如果真要考虑商业化运行，厨师提现和平台分账也是绕不开的一块，而我预留的支付抽象接口这时候就能派上用场了。

最后再分享一个小技巧：做这种前后端分离的SpringBoot项目，一定要在开发初期就把全局异常处理和统一返回结果定好，不然后面每次改接口都要返工。我在项目里用的是Result<T>包装类加@RestControllerAdvice，业务异常通过BizException抛出，未知异常统一转成500提示。联调测试的时候，这些细节会成倍节省沟通时间。