Go原生无测试套件概念，靠命名规范（如TestAuth_）+go test -run筛选、子测试（t.Run）组织逻辑分组、构建标签（//go:build integration）隔离测试类型，或谨慎引入ginkgo等第三方库。
Go 原生不支持“测试套件”（test suite）这个概念——go test 没有 TestSuite 类、没有 SetupSuite/TeardownSuite 钩子，也不允许你显式定义一组测试的执行边界。所谓“套件”，在 Go 中是靠约定、结构和工具链模拟出来的。
用 go test -run 按前缀/正则筛选测试函数
Go 的测试发现机制基于函数名：所有以 Test 开头、签名为 func(t *testing.T) 的函数都会被识别。你可以利用命名规范 + -run 参数实现逻辑分组：
TestAuth_LoginSuccess、TestAuth_LogoutExpired→ 归为 “auth 套件”go test -run ^TestAuth_只运行这些测试go test -run Auth也能匹配（但可能误中其他含 Auth 的名字，建议加^锚定开头）- 注意：正则由
go test内部解析，不是 shell 正则；特殊字符如.、+需转义
用子测试（subtest）组织可嵌套的测试结构
子测试是 Go 官方推荐的替代“套件”的方式，它共享 setup/teardown 逻辑，支持并行控制，且失败时能精确定位到子项：
func TestAuth(t *testing.T) {
t.Run("LoginSuccess", func(t *testing.T) {
// setup once per subtest, or move common setup outside
t.Parallel()
// ...
})
t.Run("LogoutExpired", func(t *testing.T) {
t.Parallel()
// ...
})
}
- 主测试函数
TestAuth可看作“套件入口”，每个t.Run是一个逻辑用例 - 子测试间默认不并行；加
t.Parallel()后才并发执行（需主测试也调用t.Parallel()） - 若想在所有子测试前统一 setup，把初始化代码放在
t.Run外；若要每子测试独立 setup，写在闭包内 - 子测试名不能重复，否则 panic：fatal error: test name "xxx" contains illegal characters
用构建标签（build tags）隔离集成/端到端测试套件
当需要区分单元测试与依赖数据库、HTTP 服务的集成测试时，Go 不靠目录或命名，而靠 //go:build 标签 + 文件后缀：
- 新建
auth_integration_test.go，顶部加//go:build integration - 运行时启用该标签：
go test -tags=integration ./... - 避免意外执行：在文件开头加
// +build integration（旧风格，仍兼容） - 标签名无限制，但建议统一管理（如
integration、e2e、slow），并在 CI 中明确指定 - 注意：同一目录下带不同 build tag 的测试文件，不会互相干扰，但必须确保
go test命令传入对应-tags
用第三方库补充高级套件语义（谨慎引入）
如果项目已重度依赖 testify 或需要 BeforeSuite 这类语义，可考虑 ginkgo（v2 要求 Go 1.18+）：
ginkgo提供Describe/Context/It块，天然支持套件层级和全局钩子- 但会引入额外 DSL 和运行时（
ginkgo run替代go test），CI 流水线需适配 - 不推荐新项目盲目上
ginkgo；优先用原生子测试 + 标签解决 90% 场景 - 若已用，注意
ginkgov2 默认启用并行，某些资源竞争问题比原生更隐蔽
真正容易被忽略的是子测试的生命周期管理：很多人把 DB 连接、临时目录创建写在主测试函数里，却忘了子测试并行时这些资源会被多个 goroutine 共享。要么加锁，要么把资源初始化移到每个 t.Run 内部——这才是 Go 式“套件”的实际约束点。
