必须用transitionto而非字符串赋值，因为硬赋值order.state="shipped"会绕过转移校验、漏记日志、并发覆盖、钩子失效，导致如支付重试与人工操作并发时状态乱序、发货单重复等线上故障。
直接用 order.State = "shipped" 赋值，等于关掉所有安全阀——并发覆盖、日志丢失、钩子不触发、状态跳变全都会发生，线上故障基本就从这儿开始。
为什么必须用 TransitionTo 而不是字符串赋值
硬赋值绕过全部校验逻辑，不是“少写一行代码”，而是放弃状态机存在的意义。
- 跳过转移合法性检查：
validTransitions[order.State][newState]根本不查，"canceled"可能直接跳到"shipped" - 漏记结构化日志：没有统一入口，就无法在每次变更时自动记录
from/to/event/traceID - 并发下覆盖变更：两个 goroutine 同时写
order.State，后写入者直接抹掉前者的意图 - 钩子函数完全失效：
OnExit(StatePaid)不会执行，导致超时任务没被取消、库存没释放、通知没发
真实场景中，支付回调重试 + 人工干预同时到达，State 字段可能从 "paid" → "canceled" → "shipped"，下游发货单发两遍是大概率事件。
TransitionTo 方法里该做和不该做的事
它是状态变更唯一合法出口，职责必须严格收口。
- ✅ 查预设转移表：
if !validTransitions[order.State][newState] { return ErrInvalidTransition } - ✅ 原子更新字段：只操作
order.State，且必须用stateMu.Lock()保护 - ✅ 立即触发钩子：
order.state.OnExit(order)和order.state.OnEnter(order) - ❌ 不调 DB：
db.Save(order)移到外面异步做，否则锁住期间整个订单不可读 - ❌ 不发 HTTP：
http.Post(...)放进 goroutine，用 channel 或回调通知完成 - ❌ 不拼错误信息：
return fmt.Errorf("can't go from %s to %s", from, to)是反模式；应返回预定义变量如ErrInvalidTransition
并发安全的关键：锁粒度不能大过状态本身
用 sync.Mutex 锁整个 *Order 结构体？那 order.UserID、order.Amount 这类只读字段的访问也会排队，压测时 QPS 断崖下跌。
- 单独声明
stateMu sync.RWMutex字段，仅包裹状态相关字段（包括临时重试计数器等） - 读状态走
stateMu.RLock()，不影响并发读取 -
TransitionTo内部只持写锁，且全程纯内存操作（无 I/O、无 channel 阻塞、无 sleep） - 若状态需维护上下文数据（如
lastRetryAt time.Time），该字段也必须受同一把stateMu保护
状态多了以后，怎么避免 switch 膨胀又不失类型安全
超过 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)，而不是在主结构体里写分支 - 接口方法必须用指针接收器，否则无法修改内部状态字段
- 状态值用自定义类型 + 枚举：
type State uint8+const StatePending State = iota，比string更安全、IDE 可补全、编译期可校验
真正容易被忽略的是：状态钩子里塞业务逻辑。哪怕只是一行 log.Info()，只要它依赖外部服务或可能阻塞，就会让整个状态流转卡住——这不是设计缺陷，是上线前最常漏掉的压测盲点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
