go原生不支持testsuite等套件概念，需用testmain统一管理资源生命周期、-tags实现逻辑分组，或谨慎使用testify/suite；goland仅辅助识别约定，不替代代码层设计。
go test 本身不支持“自定义测试套件”这个概念——Go 原生没有 TestSuite、TestGroup 或类似 JUnit 的容器机制。所谓“快速配置自定义测试套件”，本质是解决两类问题：**复用初始化/清理逻辑**，或**按需批量运行特定测试集合**。GoLand 只是帮你把这两件事做得更顺手，而不是凭空造出 Go 语言里不存在的抽象。
为什么直接写 func TestXxx(t *testing.T) 不够用？
当你面对大型项目时，常见痛点不是“测不了”，而是：
• 每个测试都要重复开 DB 连接、启 mock server、加载配置；
• 想只跑“用户模块相关测试”，但 go test -run User 会匹配到 TestUserLogin 和 TestUserService，也误拉进 TestAuditUser；
• CI 上想跳过耗时集成测试，但没统一开关，只能靠注释或删代码。
这些都不是 GoLand 能“配置出来”的功能，而是要你先在代码层明确约定，GoLand 才能识别并提供快捷操作。
用 TestMain 统一管理生命周期，GoLand 才能真正介入
GoLand 对 TestMain 有完整支持：自动识别、可调试、能高亮错误。但它不会替你写逻辑——你得自己把共享资源初始化和清理塞进去。
关键点：
• TestMain 必须定义在 *_test.go 文件中，且函数签名严格为 func TestMain(m *testing.M)；
• 不能调用 t.Fatal（因为没 t），失败要用 os.Exit(1)；
• 初始化后必须调用 m.Run()，否则所有测试都不执行；
• 如果用了临时文件、端口、容器，清理逻辑一定要放在 defer 或 os.Exit 前，否则 GoLand 调试时中断也会漏掉清理。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
用标签 + -tags 实现“逻辑套件”，而非物理套件
GoLand 不提供图形化“测试套件分组”界面，但能识别并运行带构建标签的测试。这是最轻量、最符合 Go 工具链的方案：
• 在测试函数上加 //go:build integration 或 //go:build slow（Go 1.17+）；
• 运行时用 go test -tags=integration；
• GoLand 的 Run Configuration 支持在 “Go tool arguments” 里填 -tags=integration，保存为模板后一键复用；
• 注意：标签必须同时出现在 .go 和 _test.go 文件顶部，否则编译不通过；
• 别用 build 标签拼错成 builds 或漏空行——GoLand 不会报语法错，但 go test 直接静默跳过该文件。
别碰 testify/suite，除非你真需要它
GoLand 对 testify/suite 有基础支持（跳转、重命名），但它带来的复杂度远超收益：
• 必须用 suite.Run(t, &MySuite{}) 启动，写成 t.Run 就完全失效；
• 字段状态（如 s.db）在并行测试下极易竞态，而 GoLand 无法静态检查这种数据竞争；
• 它不兼容 TestMain，二者混用会导致初始化顺序混乱；
• 如果只是想复用几个辅助函数，直接定义 func setupDB(t *testing.T) *sql.DB 更安全、更易 debug。
真正值得用 testify/suite 的场景只有一个：多个测试方法**必须共享同一个可变对象实例**，且该对象的 Setup/Teardown 成本极高（比如启动一个本地 Kafka 集群）。其他情况，都是过早优化。
TestMain）、可组合的标签系统（-tags）、以及克制的结构体封装（testify/suite 仅当必要）。GoLand 的作用，是让这些约定被严格执行，而不是绕过它们。
