订单系统是电商的心脏。很多人以为订单就是"改个状态"那么简单——付款了改成已付款，发货了改成已发货。但真正做过电商系统的都知道：订单系统最容易出事故的地方，就是状态乱转。
超卖、重复支付、退款不同步、库存扣了又加不回来、状态前后不一致……这些问题根因往往不是业务逻辑写错了，而是没有一套严格的状态机来约束。
LikeShop 单商户 Java 版的订单模块，采用的是轻量级状态机实现：枚举定义状态、事件驱动流转、补偿机制回滚，没有引入重型状态机框架，兼顾了可读性、性能和可扩展性。这篇文章从状态定义、核心实现、事件触发、回滚机制四个层面拆解。
一、为什么必须用状态机
如果不用状态机，订单代码很容易写成这样：
// ❌ 反例：随处改状态
order.setStatus(PAID);
orderDao.updateById(order);
// 顺便扣个库存
stockService.deduct(order);
// 顺便发个通知
notifyService.send(order);
这种写法的问题：
- 没有前置校验：谁都能改，当前状态能不能转到目标状态？不知道；
- 逻辑散落：改状态、扣库存、发通知散落在各个 Service 里，出问题难追溯；
- 回滚困难：某一步失败了，已经改了的状态怎么退回去？
- 无法审计：这个订单为什么从这个状态变到那个状态？谁操作的？没有记录。
状态机解决的就是这几件事：流转有规则、变更有日志、事件可解耦、失败可回滚。
二、订单状态定义与流转
2.1 核心状态枚举
LikeShop 单商户 Java 版的订单主状态定义为 8 个：
public enum OrderStatus {
PENDING_PAY(10, "待付款"),
PAID(20, "已付款"),
PENDING_SHIP(30, "待发货"),
SHIPPED(40, "已发货"),
PENDING_RECEIVE(50, "待收货"),
COMPLETED(60, "已完成"),
CANCELLED(70, "已取消"),
REFUNDING(80, "退款中"),
REFUNDED(90, "已退款");
private final int code;
private final String desc;
}
2.2 完整流转路径
正常正向流转：
PENDING_PAY 待付款
↓ 用户支付成功
PAID 已付款
↓ 商家确认（或自动）
PENDING_SHIP 待发货
↓ 填写物流单号发货
SHIPPED 已发货
↓ 用户确认收货 / 超时自动收货
PENDING_RECEIVE 待收货 → COMPLETED 已完成
逆向与异常流转：
PENDING_PAY ──超时/用户取消──→ CANCELLED
PAID ──申请退款──→ REFUNDING ──退款成功──→ REFUNDED
SHIPPED ──售后退货──→ REFUNDING ──退款成功──→ REFUNDED
COMPLETED ──售后退款──→ REFUNDING ──退款成功──→ REFUNDED
还有一条重要的回滚路径：
PAID ──库存扣减失败──→ PENDING_PAY（资金回退）
不是所有状态之间都能随便跳。比如"已发货"不能直接变回"待付款"，"已完成"不能直接变回"待发货"。每一条允许的路径，都要在状态机里显式定义。
三、数据库设计
3.1 订单主表
CREATE TABLE ls_order (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_sn VARCHAR(32) NOT NULL COMMENT '订单号',
user_id BIGINT NOT NULL,
total_amount DECIMAL(10,2) NOT NULL,
pay_amount DECIMAL(10,2) NOT NULL,
status TINYINT NOT NULL COMMENT '订单状态',
pay_time DATETIME,
ship_time DATETIME,
receive_time DATETIME,
complete_time DATETIME,
cancel_time DATETIME,
create_time DATETIME NOT NULL,
update_time DATETIME NOT NULL,
INDEX idx_user_id(user_id),
INDEX idx_order_sn(order_sn),
INDEX idx_status(status)
);
3.2 状态流转日志表（关键）
每次状态变更都写一条日志，这是审计和回滚的依据：
CREATE TABLE ls_order_status_log (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_id BIGINT NOT NULL,
from_status TINYINT NOT NULL COMMENT '变更前状态',
to_status TINYINT NOT NULL COMMENT '变更后状态',
event VARCHAR(32) NOT NULL COMMENT '触发事件：PAY/SHIP/CANCEL/REFUND...',
operator_type TINYINT NOT NULL COMMENT '1用户 2商家 3系统',
operator_id BIGINT,
remark VARCHAR(255),
create_time DATETIME NOT NULL,
INDEX idx_order_id(order_id)
);
铁则：状态变更必须写日志，不写日志的状态变更视为非法。
四、状态机核心实现
4.1 事件枚举
状态流转由事件驱动，而不是直接指定目标状态：
public enum OrderEvent {
PAY_SUCCESS, // 支付成功
CONFIRM_SHIP, // 确认发货
CONFIRM_RECEIVE, // 确认收货
CANCEL, // 取消订单
APPLY_REFUND, // 申请退款
REFUND_SUCCESS, // 退款成功
TIMEOUT_CANCEL // 超时取消
}
业务代码只发事件，不直接改状态。目标状态由状态机根据当前状态 + 事件计算。
4.2 状态转换配置
用一个 Map 定义所有允许的流转：
// 配置：当前状态 + 事件 → 目标状态
private static final Map<OrderStatus, Map<OrderEvent, OrderStatus>> TRANSITIONS = new HashMap<>();
static {
// 待付款
addTransition(PENDING_PAY, PAY_SUCCESS, PAID);
addTransition(PENDING_PAY, CANCEL, CANCELLED);
addTransition(PENDING_PAY, TIMEOUT_CANCEL, CANCELLED);
// 已付款
addTransition(PAID, CONFIRM_SHIP, PENDING_SHIP);
addTransition(PAID, APPLY_REFUND, REFUNDING);
addTransition(PAID, CANCEL, CANCELLED); // 未发货前取消
// 待发货
addTransition(PENDING_SHIP, CONFIRM_SHIP, SHIPPED);
addTransition(PENDING_SHIP, APPLY_REFUND, REFUNDING);
// 已发货
addTransition(SHIPPED, CONFIRM_RECEIVE, COMPLETED);
addTransition(SHIPPED, APPLY_REFUND, REFUNDING);
// 退款中
addTransition(REFUNDING, REFUND_SUCCESS, REFUNDED);
addTransition(REFUNDING, CANCEL, COMPLETED); // 退款驳回
}
private static void addTransition(OrderStatus from, OrderEvent event, OrderStatus to) {
TRANSITIONS.computeIfAbsent(from, k -> new HashMap<>()).put(event, to);
}
4.3 状态执行器
核心方法：transition(orderId, event, operator, remark)
@Service
@Transactional(rollbackFor = Exception.class)
public class OrderStateMachine {
@Autowired
private OrderMapper orderMapper;
@Autowired
private OrderStatusLogMapper logMapper;
@Autowired
private ApplicationEventPublisher eventPublisher;
public OrderStatus transition(Long orderId, OrderEvent event,
OperatorType opType, Long opId, String remark) {
// 1. 查询订单
Order order = orderMapper.selectById(orderId);
if (order == null) {
throw new OrderException("订单不存在");
}
OrderStatus fromStatus = OrderStatus.of(order.getStatus());
// 2. 校验：当前状态是否允许触发该事件
Map<OrderEvent, OrderStatus> map = TRANSITIONS.get(fromStatus);
if (map == null || !map.containsKey(event)) {
throw new OrderException(
String.format("状态 %s 不允许事件 %s", fromStatus, event)
);
}
OrderStatus toStatus = map.get(event);
// 3. 更新订单状态
order.setStatus(toStatus.getCode());
order.setUpdateTime(new Date());
// 根据事件填充对应时间字段
fillTimeByEvent(order, event);
orderMapper.updateById(order);
// 4. 写状态流转日志
OrderStatusLog log = new OrderStatusLog();
log.setOrderId(orderId);
log.setFromStatus(fromStatus.getCode());
log.setToStatus(toStatus.getCode());
log.setEvent(event.name());
log.setOperatorType(opType.getCode());
log.setOperatorId(opId);
log.setRemark(remark);
log.setCreateTime(new Date());
logMapper.insert(log);
// 5. 发布状态变更事件（后置业务）
eventPublisher.publishEvent(
new OrderStatusChangedEvent(orderId, fromStatus, toStatus, event)
);
return toStatus;
}
}
这就是状态机的核心入口。业务代码想改订单状态，只能调用 transition()，传事件，不能自己 updateById。
五、事件驱动：后置业务解耦
状态变更之后，往往要做很多事情：扣库存、减积分、发通知、更新统计、生成发票……
如果都写在状态机方法里，状态机会越来越胖。所以用事件发布-订阅模式解耦。
5.1 事件定义
public class OrderStatusChangedEvent extends ApplicationEvent {
private final Long orderId;
private final OrderStatus fromStatus;
private final OrderStatus toStatus;
private final OrderEvent event;
}
5.2 监听器
各个业务模块自己监听关心的状态：
@Component
public class StockOrderListener {
@Autowired
private StockService stockService;
@EventListener
public void onPaid(OrderStatusChangedEvent event) {
if (event.getToStatus() == OrderStatus.PAID) {
// 支付成功 → 扣库存
stockService.deductByOrder(event.getOrderId());
}
}
@EventListener
public void onCancel(OrderStatusChangedEvent event) {
if (event.getToStatus() == OrderStatus.CANCELLED
&& event.getFromStatus() == OrderStatus.PAID) {
// 付款后取消 → 回补库存
stockService.refundByOrder(event.getOrderId());
}
}
}
@Component
public class NotifyOrderListener {
@EventListener
public void onShipped(OrderStatusChangedEvent event) {
if (event.getToStatus() == OrderStatus.SHIPPED) {
// 发货通知
SmsService.sendShipNotify(event.getOrderId());
}
}
}
这样设计的好处：
- 状态机纯净：只负责状态流转，不掺业务；
- 可扩展：加新的后置动作，加个监听器就行，不用改状态机代码；
- 可测试：状态机和业务逻辑可以分别单元测试。
六、回滚与补偿机制
这是状态机最有价值的部分，也是最容易被忽略的部分。
6.1 为什么不能用数据库事务回滚
很多人觉得：加 @Transactional，失败了自动回滚不就行了？
不行。因为订单状态变更伴随的操作，很多是不可逆的外部操作：
- 支付成功了，退款要调用退款接口，不是数据库 rollback 就能把钱退回去；
- 库存扣减了，如果是分布式库存，要调用库存回补接口；
- 短信发出去了，收不回来；
- 积分扣了，要加回去。
这些都不是本地数据库事务能覆盖的。必须用补偿模式：每一步正向操作，都对应一个反向补偿操作。
6.2 补偿接口
public interface OrderCompensator {
/**
* 正向执行
*/
void apply(Long orderId);
/**
* 反向补偿
*/
void compensate(Long orderId);
}
每个后置业务都实现这个接口：
StockCompensator：apply 扣库存，compensate 补库存；PointCompensator：apply 扣积分，compensate 返积分；CouponCompensator：apply 核销券，compensate 退回券。
6.3 回滚执行
当状态机流转过程中某个后置操作失败，按顺序反向补偿：
public class StateMachineExecutor {
private final List<OrderCompensator> compensators;
public boolean executeWithRollback(Long orderId) {
int successStep = 0;
try {
for (int i = 0; i < compensators.size(); i++) {
compensators.get(i).apply(orderId);
successStep = i;
}
return true;
} catch (Exception e) {
// 失败了，从成功的最后一步往回补偿
for (int i = successStep; i >= 0; i--) {
try {
compensators.get(i).compensate(orderId);
} catch (Exception ex) {
// 补偿失败要告警，人工介入
log.error("补偿失败 step={}", i, ex);
alertService.send("订单补偿失败", orderId);
}
}
return false;
}
}
}
6.4 典型回滚场景
场景 1：支付成功，但库存扣减失败
- 正向：支付成功 → 改状态 PAID → 扣库存
- 失败点：库存不足
- 补偿：回补状态到 PENDING_PAY → 发起退款 → 资金退回用户
场景 2：发货后用户申请退款，退款成功
- 正向：已发货 → 申请退款 → 状态 REFUNDING
- 退款成功：状态 REFUNDED → 回补库存 → 退佣金（如果有分销）
场景 3：超时未支付自动取消
- 正向：下单 → PENDING_PAY
- 超时：状态 CANCELLED → 回补库存（如果下单时预占）→ 回优惠券
七、常见坑与设计要点
7.1 状态只能前进，不能后退？
不对。退款、取消、库存失败回滚，都是后退。状态机不禁止后退，禁止的是未定义的跳转。
7.2 并发问题
同一个订单同时两个操作（比如用户确认收货和商家申请退款同时点），会出现状态错乱。
解决方案：乐观锁。订单表加 version 字段，更新时带版本号：
<update id="updateStatus">
UPDATE ls_order
SET status = #{status}, version = version + 1
WHERE id = #{id} AND version = #{version}
</update>
版本不匹配说明别人已经改过了，抛异常重试。
7.3 日志和状态要在同一个事务
状态改了，日志没写上，崩溃后就断片了。必须在同一个本地事务里提交。
7.4 不要在事件监听器里抛异常
默认 Spring 事件是同步的，监听器抛异常会影响状态机主事务。如果是非关键路径（比如发短信），要 try-catch 掉，或者用异步事件。
7.5 终态不能再变
COMPLETED、CANCELLED、REFUNDED 是终态，终态之后不允许再流转。除非走售后流程开新的退款单。
八、结语
订单状态机看起来是个很基础的东西，但真正做扎实的系统不多。很多电商事故追溯到最后，都是"谁都能改订单状态"埋下的坑。
LikeShop 单商户 Java 版采用的这套轻量状态机，思路其实很朴素：
- 枚举定义状态和事件，流转显式配置；
- 统一入口改状态，前置校验、写日志、发事件；
- 事件解耦后置业务，各模块自己订阅；
- 补偿机制处理失败，按原路回滚。
它没有用 Spring Statemachine 这类重型框架，因为电商订单的状态数量其实不多，自己实现更轻量、更可控、出问题更好排。
对做电商系统的团队来说，订单状态机属于"地基"级别的模块——地基打牢了，上面加营销、加会员、加分销、加售后，都是顺理成章的事。
