Testify/Suite 的 SetupTest 和 SetupSuite 到底该在哪儿初始化资源
多数人把数据库连接、mock server 全塞进 SetupTest，结果跑 50 个测试用例，连 50 次 DB，慢得离谱还容易端口冲突。SetupSuite 才是共享资源的正解，但它只执行一次，且必须保证线程安全。
实操建议：
-
SetupSuite里初始化全局可读资源（如预置的 JSON 文件、只读内存 DB 实例），用sync.Once包一层更稳妥 -
SetupTest只做测试隔离操作：清空临时表、重置计数器、生成唯一testID变量 - 别在
SetupSuite里调t.Fatal—— Suite 初始化失败时，Testify 不会报错，而是静默跳过所有测试 - 如果用了
testify/suite的Run方法启动测试，确保TestingT是同一个实例，否则SetupSuite可能被重复触发
为什么 require.Equal 在 Suite 里突然不 panic 了
不是 require 失效，是你没把 *require.Assertions 绑定到当前测试上下文。Suite 默认提供的是 s.T()，它返回 *testing.T，而 require 系列函数需要显式传入或通过 require.New(s.T()) 构造。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 直接写
require.Equal(1, 2)→ 编译失败：缺少*testing.T - 写
require.New(s.T()).Equal(1, 2)→ 断言失败时 panic，但测试计数器不加一，go test显示 “PASS” 却实际中断 - 用
s.Require().Equal(1, 2)→ 正确。这是 Suite 内置的断言代理，自动关联s.T()，失败时正确标记测试为 fail
记住：Suite 里优先用 s.Require() 和 s.Assert()，别绕路 new。
并发测试下 Suite 的 TearDownTest 为什么没按预期清理
Go 测试默认并发执行（-p 控制并行度），而 Suite 的生命周期管理不是 goroutine-safe 的 —— TearDownTest 可能和下一个 SetupTest 交错运行，尤其当你在其中关 socket、删文件、改全局变量时。
使用场景：
- 如果你的测试本身带并发（比如启了多个 goroutine 模拟客户端），
TearDownTest必须等它们全部退出，用sync.WaitGroup或context.WithTimeout控制 - 避免在
TearDownTest中操作共享状态（如 global map），改用每个测试独享的结构体字段 - 文件类资源（临时目录、socket 文件）建议用
os.MkdirTemp+defer os.RemoveAll，比在TearDownTest里统一删更可靠 - 数据库事务回滚比 truncate 表更轻量，适合高频并发测试
替换 testify/suite 的替代方案是否值得尝试
Go 1.21+ 原生支持 testing.T.Cleanup 和子测试（t.Run），配合 struct 匿名嵌入 *testing.T，能实现和 testify/suite 类似的组织方式，且无额外依赖。
参数差异与影响：
-
testify/suite强制要求继承结构体 +Run启动，学习成本略高；原生方式更自由，但需手动管理 setup/teardown 链 - 性能上几乎无差别，但
testify/suite的SetupSuite在 CI 环境中偶发因 init 顺序问题失效，原生方式更可控 - 如果你已在大量代码中使用
s.Require()，迁移成本高；但新项目建议先试试t.Cleanup+ 嵌入*testing.T，尤其当团队对 testify 不熟悉时
真正难处理的从来不是语法怎么写，而是多个测试共享状态时谁负责清理、清理时机是否早于下一个测试的 setup、以及 panic 发生在 defer 里会不会吞掉原始错误 —— 这些细节，文档从不提，但线上挂过三次你就记住了。
