Go test 默认超时是10分钟，即整个go test命令运行周期的上限，由-timeout参数控制，默认值为10m；该超时无法通过代码设置，也不作用于单个TestXxx函数。
Go test 默认超时是多久？
Go 的 go test 命令本身没有全局默认超时，但单个测试函数的执行时间受 -timeout 参数控制，默认值是 10 分钟（即 10m）。这个超时是针对整个 go test 命令运行周期的，不是每个 TestXxx 函数单独计时。
- 如果一个测试卡死、死循环或阻塞在 I/O 上，10 分钟后整个测试进程会被强制终止，并报错：
signal: killed或exit status 1（取决于系统 kill 信号） - 这个超时无法通过代码控制，只能靠命令行参数调整，比如：
go test -timeout=30s - 注意：它不等于
testing.T.Timeout()—— 后者根本不存在，*testing.T没有Timeout方法
如何给单个测试函数设置超时？
Go 标准库不提供“单测粒度”的超时 API，但你可以用 context.WithTimeout + select 显式控制逻辑执行时间：
在测试函数内部启动被测逻辑（尤其是可能阻塞的操作），并传入带超时的
context.Context-
使用
select等待结果或超时，避免测试无限挂起立即学习“go语言免费学习笔记（深入）”；
-
示例：
func TestFetchDataWithTimeout(t *testing.T) { ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond) defer cancel()done := make(chan error, 1) go func() { done <- fetchData(ctx) // 假设该函数接受 context 并可取消 }()
select { case err := <-done: if err != nil { t.Fatal(err) } case <-ctx.Done(): t.Fatal("fetchData timed out") } }
关键点：被测函数必须支持
context.Context并响应取消；否则超时只作用于测试协程，无法中止实际工作
为什么 t.Parallel() 不影响超时行为？
t.Parallel() 只控制测试函数是否与其他测试并发执行，完全不改变超时逻辑：
- 超时仍以整个
go test进程为单位（由-timeout控制） - 即使 10 个测试并行跑，只要其中某一个卡住超过 10 分钟，全部测试都会被中断
- 并行测试还可能放大资源竞争问题（如共享端口、临时文件），导致某些测试看似“超时”，实则是因竞态失败后阻塞——这时应优先检查
go test -race输出
容易被忽略的超时陷阱
-
time.Sleep 在测试里不等于“等待完成”，它只是停顿；若后续逻辑仍依赖未就绪状态（如 HTTP server 尚未 bind 成功），测试可能随机失败，而非超时
- 使用
testify/assert 等第三方断言库时，断言失败不会触发超时，但若断言里包含重试逻辑且没加内部超时，就会拖垮整体测试时间
- CI 环境（如 GitHub Actions）常有更严格的进程级 timeout（例如 60 分钟 job 限制），和
go test -timeout 是两层机制，需分别配置
- 子进程（如
exec.Command）若未显式设置 cmd.WaitDelay 或用 context 控制，其生命周期不受测试超时约束，可能变成僵尸进程
time.Sleep 在测试里不等于“等待完成”，它只是停顿；若后续逻辑仍依赖未就绪状态（如 HTTP server 尚未 bind 成功），测试可能随机失败，而非超时testify/assert 等第三方断言库时，断言失败不会触发超时，但若断言里包含重试逻辑且没加内部超时，就会拖垮整体测试时间go test -timeout 是两层机制，需分别配置exec.Command）若未显式设置 cmd.WaitDelay 或用 context 控制，其生命周期不受测试超时约束，可能变成僵尸进程真正难处理的是那些不响应 context 取消、也不提供回调/通道通知的黑盒依赖。这种情况下，超时只能靠外部 kill，而 Go 测试框架不负责帮你做这件事。
