testify suite 仅在需共享初始化/清理逻辑时才引入，根本原因是未调用 suite.run(t, &mysuite{}) 导致 setuptest 不执行；结构体字段共享易引发状态污染，并行测试更需避免。
Testify suite 不是 Go 测试的默认路径，只有当你需要多个测试函数共享初始化/清理逻辑（比如共用一个内存缓存、mock HTTP server 或只读数据库连接）时，才值得引入；否则直接用原生 testing + assert/require 更轻量、更可控。
为什么 Testify Suite 的 SetupTest 没被调用
根本原因：没走 suite.Run() 入口。Go 的 go test 只认 func TestXxx(t *testing.T) 形式的函数，而 suite.Suite 里的方法（如 SetupTest、TestPutAndGet）只是普通方法，不会被自动发现或执行。
- 必须在标准测试函数里显式调用
suite.Run(t, &MySuite{})，例如：func TestCacheSuite(t *testing.T) { suite.Run(t, new(CacheSuite)) } - 结构体方法名必须以
Test开头且首字母大写，如TestPutAndGet；小写或没Test前缀的方法会被忽略 - 别在
SetupTest里调s.T().Fatal()——它会让整个 Suite 提前退出，后续所有测试都不跑
SetupSuite 和 SetupTest 该放什么逻辑
错把重资源（如 DB 连接、HTTP server）塞进 SetupTest 是最常见性能坑：50 个测试就开 50 次连接，慢、易端口冲突、还可能触发资源耗尽。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
SetupSuite：适合只初始化一次的全局只读资源，比如预加载的 JSON 配置、内存只读 DB 实例；务必用sync.Once包裹，避免并发重复初始化 -
SetupTest：只做隔离性操作，例如清空临时表、重置计数器、生成唯一testID字符串 - 别在
SetupSuite里调t.Fatal()——Testify 遇到这种错误会静默跳过全部测试，不报错也不提示
并行测试（t.Parallel）和 Suite 一起用很危险
suite.Suite 的字段（如 s.cache）是所有 TestXxx 方法共享的。一旦开启 t.Parallel()，多个测试同时读写同一字段，必然出现竞态或状态污染。
- 如果真要并行，放弃
suite，改用原生t.Parallel()+assert/require，每个测试自己管理资源 - 即使不用
t.Parallel()，只要两个TestXxx方法修改了同一个结构体字段（比如s.counter++），就可能互相干扰，尤其在 CI 环境下偶发失败 -
SetupSuite和TeardownSuite虽然只执行一次，但无法解决单个测试内字段被多方法共享的问题
断言该用 assert 还是 require
区别不在“强弱”，而在“是否继续执行”： assert.Equal 失败只打日志、返回 false，测试函数继续往下跑；require.Equal 失败则立刻调 t.Fatal()，当前测试用例终止。
- 校验初始化结果（如 DB 连接成功、配置解析无误）用
require，避免后续断言在无效状态下运行 - 校验一组独立字段（如 API 返回的
Name、Age、Email）用assert，能一次性看到所有失败项 -
require不会帮你跳过“一整组相关断言”，想实现这个效果，得靠子测试（t.Run()）或手动 if 分支
真正难的不是写对 SetupTest，而是判断哪些状态该放进结构体字段、哪些该每次重新构造——稍不注意，Suite 就从组织工具变成隐式耦合源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
