TestMain 不够用因仅支持包级初始化/清理，无法为每个测试用例独立重置状态、回滚副作用，易致测试污染和数据竞争；应改用函数创建新实例、显式管理生命周期。
Go 测试状态机时，为什么 TestMain 不够用
因为 TestMain 只能控制整个包的初始化/清理，而状态机测试往往需要每个测试用例独立重置状态、回滚副作用（比如全局变量、单例缓存、外部连接），否则测试间会互相污染。常见错误现象是：某个测试跑通，但顺序调换后失败；或 go test -race 报数据竞争。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 避免在
init()或包级变量中隐式初始化状态机实例；改用函数返回新实例：func NewStateMachine() *StateMachine - 每个测试用例显式构造、使用、销毁状态机，不复用实例（除非你明确在测“状态残留”）
- 如果依赖外部资源（如
sync.Map、数据库 mock），在SetupTest和TeardownTest中管理生命周期，而不是靠TestMain
如何让 Go 状态机测试覆盖所有转移路径
手动枚举状态 + 事件组合容易漏边角，尤其当状态数 ≥5 或事件有前置条件时。工具链不自动识别“状态转移”，所以覆盖率报告里的 if 分支覆盖 ≠ 状态转移覆盖。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把状态转移逻辑抽成纯函数：
func (s State) Transition(event Event) (State, error)，这样可批量遍历states × events组合断言输出 - 用 map 显式声明合法转移：
validTransitions = map[State]map[Event]State{S1: {E1: S2, E2: S3}}，测试时遍历该 map 驱动并验证行为 -
go test -coverprofile=c.out只能告诉你哪行执行了，要确认转移覆盖，得额外写校验逻辑：记录每次Transition调用的输入输出，最后比对是否覆盖全部 map 键值对
Go 的 testing.T 怎么支持状态机的多步时序断言
状态机行为本质是“事件序列 → 状态序列”，但 t.Run 默认只支持单步断言。直接写 sm.Handle(E1); assert.Equal(t, S2, sm.State()); sm.Handle(E2); assert.Equal(t, S3, sm.State()) 会导致失败时定位困难——不知道卡在哪一步。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用子测试封装每一步：
t.Run("E1→S2", func(t *testing.T) { ... })，并在每步开头打日志：t.Log("step 1: send E1") - 把多步流程写成 slice：
steps := []struct{ event Event; wantState State }{{E1,S2}, {E2,S3}}，循环执行并用t.Fatalf带上下文报错：t.Fatalf("step %d (%v): got %v, want %v", i, step.event, sm.State(), step.wantState) - 避免在循环里用
t.Fatal导致后续步骤跳过；改用errors.Join收集所有失败，最后统一t.Fatal
为什么 go tool cover 算不出真正的状态覆盖率
go tool cover 统计的是源码行是否被执行，不是状态节点或转移弧是否被触发。比如一个 switch state { case S1: if event == E1 { goto S2 } }，即使 S2 永远没到达，只要 case S1 分支进了，cover 就算这行覆盖了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在状态机核心方法（如
Handle）入口加日志：log.Printf("transition: %s → %s on %s", from, to, event)，测试时重定向log.SetOutput到 buffer，最后检查 buffer 是否含所有预期转移字符串 - 给状态类型实现
String()，配合map[[2]string]bool记录已触发的(from,to)对，测试结束时用assert.Len(t, transitions, expectedCount) - 别依赖 IDE 插件标绿的“覆盖率高”就认为状态逻辑安全——它只说明代码写了，没说明状态图走全了
状态机测试最难的不是写断言，是定义清楚“哪些转移必须覆盖”。业务规则变一次，转移矩阵就得同步更新，这块很容易被忽略，又没法靠工具自动发现。
