必须通过 TransitionTo 方法变更状态，因其校验转移合法性、记录日志、触发钩子、保证并发安全；禁用裸字符串，用常量定义状态；TransitionTo 内仅做内存操作并加 stateMu 写锁；状态超5–6个时应改用 State 接口实现。
为什么不能直接赋值 order.State = "shipped"
硬赋值会彻底绕过状态机的控制契约：跳过转移合法性校验、漏记结构化日志、并发下覆盖他人变更、无法触发 onExit 钩子（比如“已支付”退出时要关掉超时任务）。真实线上场景中，一次支付回调重试 + 后台人工操作同时到达，State 字段可能从 "paid" → "canceled" → "shipped"，导致发货单发两遍。
所有变更必须走统一入口：order.TransitionTo(newState string) 或 fsm.HandleEvent(e Event)。状态值必须用常量定义：const StatePaid = "paid"，禁用 "paid" 这类裸字符串。
TransitionTo 方法里该做啥、不该做啥
这个方法是状态流转唯一合法出口，职责必须单一：
- 只查预设转移表（如
validTransitions[order.State][newState]），不存在就返回ErrInvalidTransition - 成功后原子更新
order.State字段（需用stateMu.Lock()保护） - 立即调用
onEnter()和onExit()，但钩子里不放业务逻辑（避免阻塞） - 不调 DB、不发 HTTP、不
time.Sleep——耗时动作移出，改为状态变更后异步启动 goroutine - 不拼接错误信息：
return fmt.Errorf("can't go from %s to %s", from, to)是反模式，应返回明确错误变量
并发下怎么锁才不卡死整个订单结构体
订单被支付回调、风控拦截、人工干预三路同时触发 TransitionTo，如果用 sync.Mutex 锁整个 *Order，查用户 ID、读金额等只读操作也会排队，压测时 QPS 直接腰斩。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
正确做法是单独声明锁字段：
- 加
stateMu sync.RWMutex字段，粒度只包状态本身 - 读状态用
stateMu.RLock()，写状态用stateMu.Lock() -
TransitionTo内部只持写锁，且全程纯内存操作（无 I/O、无 channel 等阻塞点） - 若状态需维护临时数据（如重试次数），确保该字段也受同一把锁保护
状态多了以后，switch order.State 膨胀怎么办
当状态超过 5–6 个，硬写 switch order.State { case StatePending: } 会越来越难维护。此时该让状态自己“说话”：
- 定义
type State interface{ CanTransitionTo(to State) bool; OnEnter(o *Order); OnExit(o *Order) } - 每个具体状态（
PendingState、PaidState）实现该接口 -
Order持有state State接口值，流转时调用o.state.CanTransitionTo(newPaidState) - 注意：接口方法必须用指针接收器
状态不是“当前值”，而是“合法转移关系”的入口；一旦开始靠字符串判断和散落各处的 if order.State == "paid" 控制流程，就不是状态机，是未来线上问题的定时器。
