go test -timeout 控制整个测试命令的总耗时，如 -timeout 30m；它不作用于单个测试函数或 t.Run() 子测试，仅作为进程级“大闸门”，超时即杀进程。
go test 命令级超时用 -timeout 控制总耗时
Go 默认给整个 go test 进程设了 10 分钟超时，一旦测试套件跑太久，直接杀进程并报错：test killed with quit: ran too long (10m0s)。这不是单个测试函数的限制，而是从命令启动到结束的总时间上限。
-
-timeout必须带单位，比如go test -timeout 30m、go test -timeout 2h；只写数字（如-timeout 99999）会报错time missing unit in duration - Go 1.22+ 支持复合单位（如
5m30s），旧版本建议统一用m或s避免兼容问题 - 它不控制
t.Run()子测试，也不影响并发测试的内部逻辑——只是“大闸门”，超了就全停 - CI 环境里别只靠它，还得配平台级 timeout（如 GitHub Actions 的
timeout-minutes），防止进程卡死不退出
HTTP 接口测试中验证超时行为，得用 context.WithTimeout 或 http.Client.Timeout
测“超时”本身不是目的，关键是确认你的代码在超时发生时做了正确的事：返回 408、走 fallback、不泄露 goroutine。真实服务不可控，所以要用 httptest.Server 模拟延迟。
- 用
context.WithTimeout最灵活：构造req.WithContext(ctx)，再检查错误是否为context.DeadlineExceeded；别忘了defer cancel()，否则可能泄漏 goroutine -
http.Client{Timeout: 500 * time.Millisecond}更简洁，但它只管连接 + 请求头 + 响应体读取总时间，不包含 DNS 解析或 TLS 握手等前置开销 - 想区分连接超时和响应头超时？改用
http.Transport的DialContext和ResponseHeaderTimeout字段 - 示例中常漏掉
server.Close()，会导致端口占用、后续测试失败
别混淆：测试命令超时 ≠ 请求超时 ≠ 子测试超时
这是最容易绕晕的地方。三者完全独立：
-
go test -timeout 20m：整条命令生命周期，超了就 kill 进程 -
client := &http.Client{Timeout: 2s}：单次 HTTP 请求从发起到读完响应体的总耗时上限 - 没有原生的 “每个
t.Run()单独设超时” 机制；若需控制子测试时长，得手动加select+time.After或封装context.WithTimeout到测试逻辑里 - IDE（如 VS Code Go 扩展）可能缓存上次测试参数，改了
-timeout后没生效？试试重启测试终端或清缓存
集成测试场景下，推荐脚本化封装超时参数
手动敲 go test -timeout 30m -run "TestIntegration.*" 容易出错、难复现、团队难对齐。尤其在 CI 流水线里，硬编码超时值还可能掩盖性能退化问题。
- 写进
Makefile或 shell 脚本里，比如test-integration: go test -v -timeout 30m -run "TestIntegration.*" ./ - 配合
-v和-count=1（避免数据污染），让每次运行行为可预测 - 如果某次超时是因外部依赖变慢（如数据库响应拖长），优先排查服务健康度，而不是无脑拉长
-timeout——那只是掩盖问题
真正麻烦的从来不是设多少秒，而是超时后资源有没有被释放、goroutine 数量有没有异常增长、连接池是不是被占满。这些细节，比超时数字本身更值得盯紧。
