testing.short()用于短模式下跳过耗时操作，需在测试函数开头判断；t.skip()立即终止当前测试并标记为跳过，须在主goroutine中调用，defer仍执行。
Go 测试里 testing.Short() 和 t.Skip() 不是互斥开关，而是分层控制：前者筛场景，后者退个例。
什么时候该用 testing.Short()
它不是“跳过测试”，而是告诉测试函数：“现在跑的是短模式，别干重活”。典型用于避免 CI 或本地快速验证时执行耗时操作（如 HTTP 请求、数据库写入、大文件生成）。
- 必须在测试函数开头判断，晚了没意义 —— 比如
defer里查就无效 - 只对当前测试函数生效，不影响其他
Test*函数 - 启动时加
-short参数才为true，默认是false；CI 脚本里常带这个 flag - 别把它当条件跳过逻辑的替代品：比如用
if testing.Short() { t.Skip() }是冗余的，直接if testing.Short() { return }更干净
示例：
func TestUploadLargeFile(t *testing.T) {
if testing.Short() {
t.Log("skipping large file upload in short mode")
return
}
// ... 实际上传逻辑
}
t.Skip() 的实际触发时机和副作用
t.Skip() 会立刻终止当前测试函数执行，并标记为 “skipped”；但它的行为依赖调用位置和上下文。
立即学习“go语言免费学习笔记（深入）”；
- 必须在测试 goroutine 中调用，不能在子 goroutine 里 —— 否则 panic：
testing: t.Skip now forbidden - 调用后不会执行后续语句，但已注册的
defer仍会运行（这点常被忽略） - 如果在
subtest里调用，只跳过该 subtest，不影响外层或其他 subtest - 和
t.Fatal()不同，skip不算失败，也不会中断整个go test流程
常见误用：
func TestSomething(t *testing.T) {
go func() {
t.Skip("wrong place!") // panic!
}()
}
Short 模式 + Skip 组合的典型陷阱
两者混用时，最容易出问题的是“跳过逻辑被绕过”或“跳过不生效”，根源往往是判断顺序或作用域错位。
- 别在
init()或包级变量初始化里查testing.Short()—— 此时*testing.T还不存在，永远 false - 别把
t.Skip()放在if !testing.Short()分支外：会导致非 short 模式也跳过 - Subtest 中若需独立判断 short，每个 subtest 都得自己调
testing.Short()，外层判断不透传 - 某些集成测试框架（如
testify）封装了t，要确认其Skip()是否透传原生行为
正确组合示例：
func TestAPIEndpoints(t *testing.T) {
t.Run("GET /health", func(t *testing.T) {
// 独立判断，不依赖外层
if testing.Short() {
t.Skip("health check skipped in short mode")
}
// ... 实际请求
})
}
为什么本地开发常漏掉 -short？
因为默认不启用，而很多人只记得跑 go test，忘了加 flag。结果是：本地测得慢、CI 却快，或者反过来 —— 某些测试在 CI 里被跳过，本地却跑通了，掩盖了环境差异。
- 建议在
Makefile或scripts/test.sh里固化常用命令，比如go test -short ./... - 用
go test -v -short可看到哪些测试被 skip，方便排查遗漏 - 注意：短模式不会自动跳过所有耗时测试，得你手动加判断 —— Go 不会猜你哪段代码重
最常被忽略的一点：short 模式下，t.Parallel() 依然有效，但跳过的测试不会参与并行调度 —— 所以 skip 本身不提速，只是避免执行。
