Testify Suite 在 Go 中非必需，仅用于多个测试共享初始化/清理逻辑；必须用 suite.Run(t, &MySuite{}) 启动，且需避免并行时状态污染。
Testify Suite 在 Go 中不是必需的
Go 原生 testing 包足够支撑绝大多数测试场景，Testify Suite 主要解决的是「多个测试函数共享初始化/清理逻辑」这一特定需求。它不提供断言能力（那是 assert 或 require 的事），也不改变 Go 测试的执行模型——它只是把 TestXxx 方法包装进一个结构体，并在运行前自动调用 SetupTest、运行后调用 TeardownTest。
常见错误现象：go test 找不到测试函数，或 SetupTest 完全没被调用——根本原因是没按规范注册测试函数：必须用 s.T().Run(...) 启动子测试，不能直接写 func TestSomething(t *testing.T)。
- 只在需要跨多个测试复用状态（比如共用一个临时数据库连接、mock HTTP server、预加载配置）时才考虑 Suite
- 如果只是想复用几个辅助函数，直接定义普通函数 + 接收
*testing.T更轻量、更符合 Go 习惯 -
Testify Suite会隐式依赖testify/suite和testing，但不会自动注入t.Helper()，需手动加
如何正确声明和运行一个 Suite
关键不在结构体定义，而在测试入口函数是否调用 suite.Run。结构体本身只是个载体，真正触发生命周期方法的是 suite.Run(t, &MySuite{}) 这一行。
使用场景：你有一组测试都依赖同一个内存缓存实例，且每次测试前要清空、测试后要验证其状态。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type CacheSuite struct {
suite.Suite
cache *inmemory.Cache
}
func (s *CacheSuite) SetupTest() {
s.cache = inmemory.New()
}
func (s *CacheSuite) TestPutAndGet() {
s.cache.Put("key", "val")
s.Equal("val", s.cache.Get("key"))
}
func TestCacheSuite(t *testing.T) {
suite.Run(t, new(CacheSuite)) // ← 必须这样启动，不能写成 t.Run(...)
}
-
SetupTest/TeardownTest每个子测试都会执行一次；SetupSuite/TeardownSuite全局只执行一次 - 所有测试方法必须是
func (s *MySuite) TestXxx()形式，首字母大写的Test前缀不可少 - 不要在
SetupTest里调用s.T().Fatal—— 它会让整个 Suite 提前退出，后续测试全跳过
为什么 Testify Suite 容易导致并行测试失败
Go 的 t.Parallel() 要求测试之间完全隔离，而 Suite 的字段（如 s.cache）是共享的。一旦两个 TestXxx 并行修改同一字段，就会出现竞态或状态污染。
典型错误现象：go test -race 报数据竞争；某次测试偶尔失败，重跑又通过；TeardownTest 清理了别的测试刚写入的数据。
- 默认所有
TestXxx方法都是串行执行的，除非显式调用s.T().Parallel() - 若真要并行，必须确保每个测试操作的是独立副本（比如在
SetupTest中创建新对象，而非复用指针） - 更稳妥的做法：放弃 Suite，并行测试改用闭包封装初始化逻辑，例如
func TestCachePut(t *testing.T) { t.Parallel(); cache := newCache(); ... }
替代方案比 Suite 更 Go-idiomatic
多数情况下，用原生方式组织测试更清晰、更可控。Suite 带来的“类”抽象，在 Go 里反而增加理解成本和维护负担。
性能影响：几乎可忽略，但额外一层反射调用和方法查找，对超大规模测试集可能有微小开销；兼容性上，testify/suite 不支持 Go 的模糊测试（go test -fuzz），也无法与 bench 或 cover 深度集成。
- 共享 setup/teardown：用匿名函数封装，例如
runWithCache := func(t *testing.T, f func(*inmemory.Cache)) { c := newCache(); defer c.Close(); f(c) } - 复用断言逻辑：写普通函数，接收
*testing.T和待验值，内部调用t.Errorf或assert.Equal - 需要生命周期管理？直接用
testify/assert+ 原生defer就够了，比如db := setupTestDB(); defer db.Close()
真正难的从来不是怎么让测试“看起来像类”，而是怎么让每个测试快速失败、状态隔离、不互相干扰。Suite 容易让人误以为“封装即安全”，结果反而掩盖了共享状态的风险。
