go test -timeout 仅控制整个测试包的总时长，无法限制单个test函数；需在每个testxxx中用context.withtimeout或time.afterfunc+sync.once实现独立超时。
测试超时设置不生效？go test -timeout 只作用于整个包，不是单个 Test 函数
很多人以为加了 -timeout 5s 就能防止某个死循环的 TestFoo 卡住，结果发现它还是拖慢整轮测试、甚至被手动 Ctrl+C 中断。这是因为 go test -timeout 控制的是整个 go test 进程的最长运行时间，而非每个测试函数的上限。
真正能约束单个测试的，是 t.Parallel() 之外的 t.Run() 内部逻辑 —— 你得自己用 context.WithTimeout 或 time.AfterFunc 做主动中断。
-
go test -timeout适合防“整包挂死”，比如 CI 环境里防止无限等待 CI 超时 - 对 HTTP 调用、数据库查询、goroutine 等可能阻塞的操作，必须在测试函数内部设限
- 注意：Go 1.21+ 支持
t.Cleanup()，但清理函数本身不自动受超时保护，需手动检查t.Failed()或上下文是否已取消
testify/suite 里怎么给每个测试加独立超时？别直接套 ctx 到 SetupTest
testify/suite 的生命周期方法（如 SetupTest、TearDownTest）没有内置上下文参数，硬塞 context.Context 会导致编译失败或行为不可控。正确做法是在每个 TestXxx 方法里单独构造带超时的 context.Context，再传给被测逻辑。
常见错误是把超时逻辑写在 SetupTest 里，以为能“统一管控”，结果超时触发时 t.Fatal 在非测试 goroutine 中调用，panic 并静默退出。
立即学习“go语言免费学习笔记（深入）”；
- 每个
TestXxx方法开头用ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) - 用
defer cancel()确保释放，但注意：如果测试提前t.Fatal，cancel()仍会执行，不影响正确性 - 被测函数若接受
context.Context，直接传入；否则需改造成支持上下文的版本，或用time.AfterFunc配合sync.Once触发强制失败
用 time.AfterFunc 强制中断长时间运行的测试？小心竞态和多次 t.Fatal
有些场景无法改被测代码（比如第三方库黑盒调用），只能靠外部“掐断”。time.AfterFunc 是常用手段，但它本质是启动一个新 goroutine，和主测试 goroutine 并发执行，容易引发竞态：比如 t.Fatal 被调两次，或超时后主流程还在继续执行。
关键点是确保只触发一次失败，并让主流程感知中断。
- 用
sync.Once包裹t.Fatal调用，避免重复 panic - 不要依赖
time.AfterFunc后的代码“自然停止”——它不会终止正在运行的 goroutine，只是发信号 - 更稳妥的做法是配合
channel+select：主逻辑监听ctx.Done()或超时chan struct{}，收到后主动退出 - 示例片段：
done := make(chan struct{})<br>timeout := time.AfterFunc(2*time.Second, func() { once.Do(func() { t.Fatal("test timed out") }) })<br>defer timeout.Stop()<br>// 主逻辑里 select { case <-done: ... case <-time.After(2*time.Second): ... }
CI 环境中测试超时表现异常？检查 GOMAXPROCS 和资源限制
本地跑得好好的测试，在 GitHub Actions 或 GitLab CI 上频繁超时，往往不是逻辑问题，而是资源受限导致调度延迟。Go 运行时默认用 GOMAXPROCS 设置 P 的数量，而 CI 容器常被限制为 1 或 2 个 CPU 核心，大量 goroutine 争抢导致实际执行变慢，原本 800ms 的测试可能拖到 3s+ 才完成。
另一个隐藏因素是：某些云 CI 会动态调整 cgroup CPU quota，time.Now() 和 time.Sleep() 在低配容器里精度下降，影响基于时间判断的逻辑。
- CI 中显式设置
GOMAXPROCS=2（或根据 runner 规格设为$(nproc)）可缓解调度抖动 - 避免在测试中依赖绝对时间差（如
time.Since(start) ），改用相对宽松阈值（如 <code>）或重试机制 - Docker 容器内若启用了
cpu.cfs_quota_us，runtime.GOMAXPROCS应 ≤ CFS quota / period，否则大量 goroutine 饥饿
超时不是开关，是压力计——它暴露的常常不是测试写错了，而是环境、依赖或并发模型的真实瓶颈。调大 timeout 数值最省事，但掩盖问题；真正要盯住的，是那个在 99% 场景下快如闪电、唯独在 CI 里慢半拍的 goroutine。
