go用interface+struct实现状态机，通过统一handleevent方法返回新状态实例而非修改字段，确保不可变性与并发安全；各状态struct实现state接口，事件处理需幂等校验与错误返回，测试应直接构造真实对象验证迁移结果。
Go 里用 interface + struct 实现状态机，别写 switch-case 堆砌
订单状态流转不是靠一堆 if-else 或 switch state 硬编码出来的。那样一来逻辑散、难测试、加个「已退款中」就得改五六处。Go 没有继承多态的语法糖，但用 interface 定义行为契约 + 每个状态一个 struct 实现，能自然隔离变化。
关键在定义统一入口：让所有状态都实现 HandleEvent 方法，传入当前订单和事件，返回新状态。不是“修改状态字段”，而是“返回下一个状态实例”。这样状态不可变、无副作用、可并发安全。
-
Order结构体只存业务数据（ID、金额、创建时间），不存state字段；状态本身是值，不是属性 - 每个状态类型（如
CreatedState、PaidState）实现同一个State接口，方法签名必须一致 - 禁止在状态实现里直接修改
order.state = xxx—— 这会破坏状态对象的纯度，也掩盖了流转意图
「支付成功」事件触发状态迁移时，如何避免重复处理或中间态丢失
真实场景中，支付回调可能重试多次，或者前端连点两次「确认支付」。如果每次回调都执行 order.TransitionTo(PaidState{})，而 PaidState 的 HandleEvent 又没做幂等判断，就可能把「已支付」又变成「已支付」，甚至误触发下游发货逻辑。
正确做法是在事件处理器里先校验前置条件，而不是依赖外部调用顺序：
立即学习“go语言免费学习笔记（深入）”；
- 在
PaidState.HandleEvent中，收到PayEvent时直接返回自身（不新建），并记录日志说明“忽略重复支付事件” - 在
CreatedState.HandleEvent中，才真正响应PayEvent并返回PaidState{} - 所有事件结构体建议带唯一 ID（如
event.ID），状态机可缓存已处理的 ID，用于跨进程幂等（需搭配 Redis 或 DB）
状态迁移失败时 panic 还是返回 error？Go 习惯怎么选
订单从「已发货」收到「取消订单」事件，按规则是不允许的 —— 这不是程序 bug，而是业务约束。这类非法迁移不能用 panic，也不该静默吞掉。Go 的惯用法是让 HandleEvent 返回 (State, error)，error 表示迁移被拒绝。
- 错误类型建议用自定义 error，比如
ErrInvalidTransition，方便上层做分类处理（告警 / 降级 / 返回用户提示） - 不要用字符串比较判断错误，用
errors.Is(err, ErrInvalidTransition) - 如果上层不关心失败原因，只希望“失败就保持原状”，那返回的
State应该是当前状态本身，而非 nil —— nil 会让调用方不得不额外判空
测试状态机时，为什么 mock 数据比 mock 方法更可靠
写单元测试时，别去 mock HandleEvent 方法的行为。Go 的接口实现是隐式绑定的，mock 方法容易绕过真实状态逻辑，测了个寂寞。
真正要测的是：给定某个状态 + 某个事件 → 是否得到预期的新状态 + 是否返回预期 error。所以直接构造真实状态 struct，传真实事件，断言返回值即可：
func TestCreatedState_HandleEvent_PayEvent(t *testing.T) {
s := CreatedState{}
order := &Order{ID: "123"}
newState, err := s.HandleEvent(order, PayEvent{})
if err != nil {
t.Fatal(err)
}
if _, ok := newState.(PaidState); !ok {
t.Error("expected PaidState")
}
}
- 每个状态测试文件只测它自己响应哪些事件，不测其他状态怎么处理同一事件
- 事件结构体尽量保持简单（字段少、无方法），避免测试时被嵌套逻辑干扰
- 别在测试里 new 出完整订单服务或数据库连接 —— 状态机本身应是纯内存计算，依赖越少，边界越清晰
状态机真正的复杂点不在代码结构，而在状态定义是否穷尽、事件命名是否反映真实业务动作、以及迁移规则有没有写进文档。代码写得再漂亮，如果「已超时未支付」和「已关闭」被当成两个独立状态却共享同一套取消逻辑，问题照样爆发。
