测试总在中间步骤 panic 是因为 mock 未按状态流精确配置：同一方法多次调用需分别 On，Times(1) 约束次数，Return() 按子流程返回对应值，否则 mock.Mock 遇未预期调用即 panic。

用 testify/mock 模拟状态机依赖时，为什么测试总在中间步骤就 panic？

因为状态转化流程里常含不可控外部调用（比如发 HTTP 请求、查 DB），直接跑真实逻辑会导致测试不稳定或无法覆盖边界分支。但若 mock 不够细，mock.Mock 会因未预期的方法调用而 panic——尤其当状态流转中多次调用同一接口、仅参数不同却没区分 Expect 时。

• 每个状态跃迁前的校验、跃迁后的副作用都要单独 On，不能只写一次 On("DoAction") 就完事
• 用 Times(1) 显式约束调用次数，避免漏掉某次调用导致后续断言失败
• 如果依赖方法返回值影响下一步状态判断，必须用 Return() 提供符合当前子流程的响应，而不是固定返回 nil
• 示例：状态从 "pending" → "processing" 需要 svc.Validate(ctx, id) 返回 nil；而 "processing" → "done" 则要求 svc.Commit(ctx, id) 返回 err == nil，两个 On 必须分开写

table-driven tests 跑状态流时，如何组织 case 才不漏掉非法跳转？

状态转化不是线性路径，而是有向图：某些状态之间根本不能直连（如 "failed" 不能直接回到 "pending"）。靠人工列 case 容易忽略非法输入，结果测试“看似通过”，实则没验证守门逻辑。

• case 结构里必须包含 from、to、inputEvent、expectedError 四个字段，缺一不可
• 显式列出所有合法跳转对，再反向生成“非法跳转” case（比如遍历所有 from != to 且不在白名单里的组合）
• 不要在 table 循环里做状态累积（如上个 case 把对象改成了 "done"，下个 case 还拿它试 "pending"→"processing"），每个 case 必须从干净初始状态开始
• 示例：

  cases := []struct {
  	from, to, event string
  	errIsNil       bool
  }{
  	{"pending", "processing", "start", true},
  	{"processing", "done", "finish", true},
  	{"processing", "failed", "fail", true},
  	{"failed", "pending", "retry", false}, // 这个应该失败，errIsNil = false
  }

为什么 t.Parallel() 一开，状态流测试就随机失败？

因为多数状态管理代码默认共享内存（比如用全局 map 存实例、用 struct 字段存当前状态），并发执行时多个 goroutine 同时读写同一对象，结果不是状态错乱就是 panic: “concurrent map read and map write”。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 测试函数内创建的被测对象必须是全新实例，不能复用包级变量或 init 初始化的单例
• 如果被测类型含 sync.Mutex 或 RWMutex，确保每次调用前都已初始化（比如在 test case 里 new 一个，而不是用指针指向同一个）
• 避免在测试中启动 goroutine 后不等它结束（比如模拟异步回调），否则 t.Parallel() 下时间线完全不可控
• 简单验证方式：先关掉 t.Parallel()，所有 case 全绿；再打开，某个 case 偶发失败 → 基本锁定是状态共享或竞态问题

用 go test -race 发现数据竞争，但业务代码里明明加了锁？

常见原因是锁保护范围不对：只锁了写操作，没锁读；或者锁的是局部变量而非实际被共享的结构体字段；更隐蔽的是 defer unlock 写错位置，导致锁提前释放。

立即学习“go语言免费学习笔记（深入）”；

• 检查锁作用域是否覆盖所有访问该状态字段的路径，包括 error 分支、early return 前的读取
• 确认 mutex 字段是导出的（首字母大写）且被正确嵌入，而不是定义在函数内或作为参数传入后又被忽略
• 别用 sync.RWMutex 的 RUnlock() 配 Lock()，这种错配不会编译报错，但 runtime 会直接 crash
• 示例错误：

  func (s *Order) SetStatus(st string) {
  	s.mu.Lock()
  	defer s.mu.Unlock() // ✅ 正确
  	s.status = st
  }
  func (s *Order) GetStatus() string {
  	s.mu.RLock()
  	// 忘了 defer s.mu.RUnlock() ❌
  	return s.status
  }

状态流转测试最难的不是写 case，是让每个状态变更都可重现、可隔离、可断言。最容易被忽略的，是那个没写 defer 的 RUnlock，和那个被多个 test 共享的 struct 实例。