beego中应通过独立状态类（如paidstate）实现orderstate接口，订单model内嵌状态指针，controller仅调用order.transitionto()触发校验、变更与持久化，所有状态逻辑下沉，禁止if-status硬判断。
Beego 框架本身不内置状态机，但结合其 Controller 生命周期、Model 层封装和自定义中间件，完全可以落地订单状态机模式——关键不是“用哪个库”，而是状态流转逻辑是否被显式建模、是否与业务动作解耦。
Beego 中如何组织状态类与上下文对象
别把状态写成一堆 if status == "paid" { ... }。Beego 的 Controller 适合做动作入口，状态行为应下沉到独立结构体中。例如定义一个 OrderState 接口，再实现 PendingState、PaidState、ShippedState 等具体类型：
-
OrderModel 内嵌当前状态指针（如state OrderState），避免每次查 DB 判状态 - 每个状态实现
CanCancel() bool、OnPay(*Order) error等方法，把“能否支付”“支付后改什么字段”逻辑收进状态内部 -
Order提供TransitionTo(newStatus string) error方法，统一校验 + 执行 + 持久化，而不是让 Controller 直接调o.Status = "paid"
这样，Controller 只需写 order.TransitionTo("paid")，状态合法性、副作用（如发消息、扣库存）都由对应状态类控制。
Beego ORM 与状态变更的事务一致性
状态变更常伴随多表更新（订单主表、订单快照、库存记录等），Beego 的 orm.RunTransaction 必须用，且要包裹整个状态迁移过程：
- 不要在
OnPaid()里单独开事务——它只是状态行为的一部分，事务边界应在TransitionTo()外层 - 状态类内部只做内存操作或调用 ORM 方法，不主动
Save；最终由上下文统一o.Save()或批量InsertMulti - 注意 Beego ORM 的
Save默认不更新空值字段，若状态变更需重置某些字段（如cancel_reason），得显式赋值再 Save
否则容易出现 DB 状态已更新，但关联记录未写入，或部分写入后 panic 导致不一致。
Beego 路由与状态动作的映射陷阱
别让一个 API 接口处理所有状态变更。例如 /order/:id/pay 应只响应“支付请求”，而不是在里面判断“如果未支付就付，已发货就拒”。正确做法是：
- 路由按动作命名，而非状态名：
/order/:id/cancel、/order/:id/ship、/order/:id/confirm_receipt - 每个 Action Controller 先查订单，调
order.CanCancel()校验，失败直接返回 409 Conflict + 错误码（如"cannot_cancel_paid_order"） - 避免在 Controller 里写
switch order.Status { case "pending": ... case "paid": ... }—— 这等于把状态机逻辑又拉回了胶合层
Beego 的 Prepare() 方法适合做前置校验，但状态检查必须基于当前订单实例，不能依赖 URL 参数或 session 猜测状态。
Beego 日志与状态变更审计的结合点
订单状态变更是核心审计事件，Beego 的 logs 模块可打点，但要注意两点：
- 日志必须包含变更前/后状态、触发人（
ctx.Input.Session.Get("user_id")）、时间戳、订单 ID，且建议用结构化 JSON 输出，方便 ELK 收集 - 不要只在 Controller 打日志——状态类的
OnXxx()方法内也要记，因为有些状态流转可能来自定时任务或消息队列回调（比如超时自动关单），不走 HTTP 路由 - Beego 的
logs.Async(true)开启异步写入，避免阻塞状态流转；但需确保进程退出前 flush 日志，尤其在main.go的defer logs.Close()
真正难的不是实现状态跳转，而是当“用户点了两次支付按钮”或“支付回调重复到达”时，状态机能否幂等处理——这需要在 OnPay() 里加唯一性判断（如查是否存在相同支付流水号），而不是靠上层重试机制兜底。
