Go 订单状态机怎么设计：用显式状态替代一组互相打架的布尔字段

运营同事刚把一笔“已发货”的订单标成了“已取消”，支付回调随后又把它改回“已支付”。代码里找不到明确的单点bug，只有 paid、shipped、cancelled 三个布尔字段各自正常完成逻辑，最后却拼出了一组业务上根本不存在的非法状态。

为什么三个布尔字段会把订单带进死胡同

刚起步的时候用布尔字段写状态逻辑很省事：支付成功就写 paid=true，发货时写 shipped=true，取消时写 cancelled=true。问题在于三个字段是完全独立存储的，数据库层面根本不会替业务校验它们之间的依赖关系。

于是下面这些离谱的组合都可能在生产环境出现：paid=false, shipped=true，表示货已经发出去了但订单还没收到钱；shipped=true, cancelled=true，表示订单同时标记为已发货和已取消；三个字段全为 false 时，你甚至没法区分它是刚生成的新订单，还是退款已经走完的终态订单。后续为了修补这些异常组合，你只会不断堆出更多互相冲突的if判断，下一个边缘场景的回调请求很容易就绕开了之前补的校验逻辑。

更稳妥的做法是让订单只保留一个 status 字段，比如常见的 pending_payment、paid、shipped、cancelled。状态机的价值根本不是画几张UML图，而是把所有合法的状态迁移规则收敛成一处可复用的统一判断逻辑。

先把合法迁移规则落进代码

先把当前业务场景下订单允许跳转的所有状态边列清楚，再动手写Go代码。一个简化版的电商订单状态流转规则可以这样定义：

package order

import "fmt"

type Status string

const (
	PendingPayment Status = "pending_payment"
	Paid           Status = "paid"
	Shipped        Status = "shipped"
	Completed      Status = "completed"
	Cancelled      Status = "cancelled"
)

var transitions = map[Status]map[Status]bool{
	PendingPayment: {Paid: true, Cancelled: true},
	Paid:           {Shipped: true, Cancelled: true},
	Shipped:        {Completed: true},
}

func (s Status) CanMoveTo(next Status) bool {
	return transitions[s][next]
}

func Move(current, next Status) error {
	if current == next {
		return nil
	}
	if !current.CanMoveTo(next) {
		return fmt.Errorf("invalid order transition: %s -> %s", current, next)
	}
	return nil
}

后续所有调用方只需要提交“当前状态”和“目标状态”两个参数，不用知道每个状态的全部流转细节。支付回调、仓库服务和用户取消逻辑全部共用 Move 这一套校验规则，所有非法的 shipped -> paid 都会在进入持久化层之前就被直接拦截。

迁移表就是业务规则的天然边界

别把状态迁移的校验逻辑散落在支付、发货、取消三个独立的handler里面。后续如果要新增“退款中”或者“部分发货”这类新状态，你只需要先改迁移表和对应的单元测试，再把新的业务事件接入进来就好。状态命名尽量直接表达业务含义，不要用 flag_3 这类看完日志都没法直接读懂的自定义值。

数据库条件更新是最后一道安全闸

内存里做的状态校验挡不住并发场景的问题。假设订单 OD20260720A17 当前状态仍是 paid，仓库发货请求和用户取消请求刚好同时到达：两个请求都先读到了同样的 paid 状态，随后各自在内存里通过了 CanMoveTo 校验。如果更新语句只按订单号做匹配，后写入数据库的请求就会直接覆盖前一个请求的结果。

把你之前读到的旧状态直接放进更新条件里，操作完成后再校验数据库返回的影响行数：

UPDATE orders
SET status = ?, updated_at = CURRENT_TIMESTAMP
WHERE order_no = ? AND status = ?;

在Go项目的仓储层代码里，判断到 RowsAffected 为0的时候不能直接静默吞掉错误。这个返回结果可能表示订单不存在，也可能表示另一个并发请求已经抢先完成了状态迁移；两种情况都需要重新读取订单数据，同时记录完整的处理上下文。

func (r *Repo) Move(ctx context.Context, no string, from, to Status) error {
	if err := Move(from, to); err != nil {
		return err
	}
	result, err := r.db.RunUpdate(ctx, `
		UPDATE orders
		SET status = ?, updated_at = CURRENT_TIMESTAMP
		WHERE order_no = ? AND status = ?`, to, no, from)
	if err != nil {
		return err
	}
	n, err := result.RowsAffected()
	if err != nil {
		return err
	}
	if n != 1 {
		return fmt.Errorf("order state changed before update: %s", no)
	}
	return nil
}

这里返回给上层的错误信息要带上订单号和操作时期望的旧状态，但不要把完整的支付凭证这类敏感数据写进日志里。上层业务可以把“状态已经发生变更”的提示转成对应幂等成功响应，也可以重新读取订单数据后，判断目标状态是不是已经被另一条相同的事件提前处理完成。

哪些场景不需要强行套统一状态机

状态机最适合“同一时刻只有一个主状态，而且状态迁移边界清晰”的业务对象。订单的物流状态、退款状态、发票状态本来就是各自独立流转的，如果硬要把所有子状态都塞进订单的一个枚举字段里，状态组合的数量会指数级膨胀，很快就没法维护。

这种场景下你可以保留订单的主状态机，再为退款、物流这类独立域单独搭建对应的状态机；也可以把所有不可逆的业务动作都记录成独立事件，比如 payment_captured、warehouse_picked。不要为了少数几个字段看起来整齐，牺牲后续数据查询和事件回放的可读性。

别把“取消”做成万能回退键

订单已经发货之后的取消操作，从来不是简单把状态直接改回之前的值就行，它往往需要触发拦截物流、生成退款单、等待人工审核等一系列后续流程。更稳妥的做法是新增 cancel_requested 状态，或者单独设计独立的退款状态机，等异步流程全部走完之后，再把订单流转到对应的终态。

上线前对照迁移表做一轮完整验收

• 给每一条合法的状态迁移边写成功用例，为每个终态写拒绝非法跳转的用例。
• 模拟支付回调和发货请求同时更新同一个订单的场景，确认最终只有一个请求能执行成功。
• 验证重复回调逻辑：相同的事件再次到达时，不会重复扣减库存、不会重复发起退款。
• 日志统一包含 order_no、from_status、to_status、source 和最终处理结果。
• 为数据库里已经存在的无法识别的旧状态预留告警和人工修正的路径，不要直接把这类异常订单当成初始的待支付状态处理。

相关问题

状态机一定要用第三方库实现吗？

不一定。如果状态数量不多、迁移关系长期稳定，Go原生的枚举加map结构就足够实现需求；只有当你需要做事件持久化、可视化迁移面板或者复杂的守卫条件时，再考虑引入对应的开源状态机库。

为什么做完内存校验之后还要额外做数据库条件更新？

内存里的校验只能说明某个瞬间你读到的状态允许做当前迁移，根本没法锁住另一个同时到达的并发请求。旧状态条件匹配和影响行数校验这一步，才是把状态合法性判断延伸到了真正执行数据写入的环节。

重复支付回调来了应该直接报错吗？

先判断对应事件有没有提前处理过。如果订单已经是目标状态而且事件标识相同，可以按幂等成功返回给上游；如果当前订单状态和目标状态不一致，就记录冲突信息之后进入人工或者补偿流程处理。

把状态定义清楚，后续的业务代码会省心很多

显式状态机解决的是“哪些状态变化属于合法操作”的问题，数据库条件更新解决的是“并发场景下谁能最终写入数据”的问题，事件标识和完整日志解决的是“出了线上问题能不能回溯归因”的问题。这三层逻辑不能互相替代：只写枚举定义没有并发保护还是会出现脏数据，只写条件更新没有前置业务边界会把非法状态流转漏到持久化层，只记日志又没法提前拦截错误状态进入系统。