Go中应以函数类型type State func() State替代结构体字段存状态，避免逃逸、并发误改及测试难mock；状态转移通过纯函数调用链推进，禁止闭包捕获可变变量，确保类型安全、错误显式处理与异步副作用分离。
用 func() State 替代结构体字段存状态
状态逃逸到堆上、被多个 goroutine 误改、或在测试时难 mock，根本原因常是把 state 当普通字段塞进 struct。Go 里更轻量且可控的方式，是让状态本身成为函数——每次调用返回下一个状态函数，不依赖外部变量。
典型写法：type State func() State，初始化时返回首状态函数，后续所有转移都靠函数调用链推进。比如：
func Idle() State {
return func() State {
fmt.Println("waiting for input...")
return Running()
}
}
这样避免了 machine.state = Running 这类硬赋值，也天然屏蔽了非法跳转（没定义对应函数就编译不过）。
- 别在闭包里读写外部
state变量——那只是“带状态的函数”，不是“状态即函数” - 每个状态函数必须有明确退出路径：返回
nil表示终止，或返回另一个State函数 - 若需携带数据（如重试次数），用参数传入，不要靠闭包捕获可变变量，否则并发下会错乱
泛型 State[T] 怎么避免类型擦除和运行时 panic
用 type State[T any] func(context.Context, T) (T, State[T], error) 能让输入输出类型对齐，但容易踩两个坑：一是泛型参数 T 在 runtime 是擦除的，reflect.TypeOf 看不到具体类型；二是错误处理没覆盖全，error 被忽略后状态机静默卡死。
立即学习“go语言免费学习笔记（深入）”；
实操要点：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有事件类型必须是具名 struct（如
type PayEvent struct{ OrderID string }），禁用interface{}或map[string]interface{}做事件载体 - 在
State[T]的实现里，用switch e := event.(type)显式分支，IDE 和 go vet 都能帮你发现漏处理的事件类型 - 返回
error时，必须确保上层有统一兜底逻辑（比如记录日志 + 进入ErrorState），不能只靠调用方判断
为什么 TransitionTo 不能直接调 DB 或发 HTTP
状态变更卡顿、超时、重复触发，90% 源于把耗时操作塞进 TransitionTo 方法。比如支付成功后立刻查余额、调物流接口——这些不是状态转移，是状态转移后的副作用。
正确分工：
-
TransitionTo(StatePaid)只做三件事：校验是否允许跳转、更新内存中state字段、发OrderPaid事件 - 余额扣减、通知下游、生成发货单，全部移出，改由监听
OrderPaid事件的 handler 启动 goroutine 异步执行 - 如果异步任务失败需回滚状态，不能在 handler 里调
TransitionTo(StatePending)——而应发PaymentFailed新事件，由状态机统一响应
并发下 SetState 怎么不锁整个对象
订单服务压测时 QPS 腰斩，往往是因为 TransitionTo 锁了整个 *Order 结构体。状态字段只是其中一小块，没必要让查用户信息、读订单金额都排队。
最小化锁粒度的关键是分离关注点：
- 单独声明
stateMu sync.RWMutex字段，只保护currentState的读写 -
GetState()用RLock()，不影响其他字段并发访问 -
SetState(s State)用Lock()，但内部只做machine.currentState = s+log.Printf("state changed to %v", s)，绝不调外部函数 - 如果状态需要临时元数据（如“当前重试第几次”），用
sync.Map单独存，别塞进状态 struct
真正难处理的不是状态切换本身，而是状态切换与异步任务生命周期的对齐——比如 Running 状态启了一个上传 goroutine，但用户中途调 Cancel，这个 goroutine 必须能被 ctx 取消，且 Exit() 方法要等它结束才真正切到 Canceled。这点很容易被忽略，却直接决定系统是否可靠。
