testing.Short()必须在每个测试函数开头显式判断并调用t.Skip()才能跳过，否则加-short也无效；它不自动识别耗时、不作用于TestMain或defer，仅对当前函数生效，且只响应-short参数而非实际运行时间。
testing.Short() 必须在测试函数开头显式判断
GoLand 本身不提供图形化开关跳过耗时测试，真正起作用的是 Go 原生的 testing.Short() 机制——但它不会自动生效。你得在每个想跳过的测试函数里手动写判断逻辑，否则哪怕你在 GoLand 的运行配置里加了 -short，测试照样执行到底。
常见错误是把 if testing.Short() { t.Skip() } 放在 setup 之后，比如 DB 连接、HTTP server 启动完成才检查。这时资源可能已申请失败，跳过也晚了。
- 必须放在
func TestXxx(t *testing.T)进入后的第一行 - 不要放在
TestMain或defer里——TestMain没有*testing.T，defer执行太晚 - CI 脚本常用
go test -short -timeout=30s ./...，但timeout和testing.Short()互不影响
集成测试推荐用 *_integration_test.go 文件隔离
不是所有慢测试都适合靠 testing.Short() 控制。更稳妥的做法是物理隔离：把依赖数据库、外部 HTTP 服务、消息队列的测试，统一放到命名含 _integration_test.go 的文件里（比如 service_integration_test.go）。这样你可以在 CI 中明确排除：
- 本地开发时跑全部：
go test ./... - CI 快速通道只跑单元测试：
go test ./... -run '^Test.*' -exclude '_integration_test\.go$' - 或直接按文件名过滤：
go test $(go list ./... | grep -v integration)
文件名隔离比代码内判断更可靠，避免漏写 testing.Short() 导致某次 CI 拉垮。
t.Skip() 和 return 的行为差异不能忽略
两者都会退出当前测试函数，且已注册的 defer 都会执行。关键区别在于语义和日志输出：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
t.Skip("reason")会在测试输出中标记为SKIP，CI 日志里一目了然，不影响整体成功率 -
return是静默退出，没有日志记录，容易误判为“没跑”或“卡死” - 如果用了
t.Cleanup()，它会在t.Skip()后照常触发，但清理逻辑应写在t.Skip()之前，或确保t.Cleanup()本身是幂等的
别在 goroutine 里调用 t.Skip()——会 panic：testing: t.Skip now forbidden。
GoLand 运行配置里怎么加 -short 参数
GoLand 默认运行配置不带 -short，需要手动添加：
- 右键测试函数 → “Run ‘TestXxx’” → 点击右上角齿轮图标 → “Edit Configurations…”
- 在 “Program arguments” 栏填入：
-short -timeout=60s（注意不是 “VM options”） - 勾选 “Add content root to GOPATH”（避免 module 模式下路径解析异常）
- 保存后下次运行就自动带上
-short，前提是你的测试代码里写了if testing.Short() { t.Skip(...) }
IDE 缓存可能导致参数修改后不生效，改完记得点 “Apply” 再重新运行，别只点 “OK”。
最易被忽略的一点：testing.Short() 只响应命令行参数，不感知实际耗时。它不是性能监控开关，而是人工约定的“快速反馈模式”开关——该跳哪些、为什么跳，得由开发者自己定义清楚。
