Go testing.T.Deadline 怎么让子测试提前停止昂贵准备

如果一组 Go 子测试都会先加载大文件、建立测试容器或生成大量样例，最容易浪费时间的地方往往不是断言，而是“已经没有足够时间，却仍然开始准备”。处理办法是：从 t.Deadline() 取得测试的绝对截止时间，在准备前检查剩余预算，再把这个时间传给真正支持取消的准备函数。

官方地址：https://pkg.go.dev/testing

先看清 t.Deadline 能解决什么

t.Deadline() 返回两个值：截止时刻和是否存在截止时间。这个截止时刻来自测试命令的 -timeout，因此父测试与它创建的子测试共享同一份测试运行预算。它适合回答“现在还有没有时间开始一次昂贵准备”，不等于为每个子测试自动创建了独立的超时。

另一个容易混淆的点是，测试超时本身不会替你停止任意 goroutine。若准备函数正在等待网络、通道或外部进程，必须把取消信号继续传下去，否则外层测试即使结束，后台工作仍可能泄漏。

在子测试开始昂贵准备前做一次预算判断

下面的辅助函数把截止时刻交给准备阶段。示例使用一个假的准备接口表示真实工程中的数据库连接、容器启动或样例生成；代码重点是边界判断和取消责任。

package cachetest

import (
    "context"
    "fmt"
    "testing"
    "time"
)

func prepareFixtures(ctx context.Context) error {
    // 真实实现可在这里调用支持 Context 的 HTTP、数据库或容器 API。
    select {
    case 

这里的 900ms 不是 testing 包规定的固定值，而是这个准备阶段的工程预算。若准备通常需要 2 秒，就应按真实耗时和断言成本调整。重点是把“是否值得开始”放在昂贵操作之前，而不是等测试超时后才发现。

为什么只调用 Deadline 仍可能停不下来

时间判断只能阻止尚未开始的工作。已经进入准备函数后，函数必须主动观察 ctx.Done()，或者调用本身就支持 context 的库方法。对不可取消的纯 CPU 循环，可以在循环内定期检查 ctx.Err()；对一次性阻塞调用，则应改用带 context 的 API。

多个子测试和清理阶段的边界

如果多个子测试共享昂贵资源，应把资源准备放在父测试中，并在每个子测试开始前只做轻量检查；如果每个子测试都独立准备，就要为每次准备保留预算。并行子测试还会受到父测试整体生命周期影响，不能用共享可变资源来假设它们会按顺序释放。

t.Cleanup 适合释放临时目录、连接和测试替身，但清理函数本身也要短小、可结束。不要把一个无法取消的长任务放进 cleanup，再期待 t.Deadline 替你终止它。

常见问题

t.Deadline 返回的是子测试自己的超时时间吗？

不是。它反映测试二进制的 -timeout 截止时间，子测试通常应把它当作共享总预算来分配。

没有设置 -timeout 时可以直接使用 deadline 吗？

不可以。此时 ok=false，请显式决定是否添加测试内预算，或让准备按原策略执行。

调用 t.Skip 就能取消已经开始的网络请求吗？

不能。Skip 只改变测试流程；网络请求仍需使用带截止时间的 context，并由调用方正确处理取消。

应该用 t.Context 代替 t.Deadline 吗？

两者用途不同。需要计算剩余绝对时间时用 Deadline；需要把测试结束前的取消信号传给资源清理或协作任务时，再考虑使用测试提供的 context。

把截止时间传进准备阶段后，子测试就能在“开始昂贵工作”之前做出判断；真正的阻塞工作则通过 context 响应取消。这样既减少无意义的准备，也不会把测试超时误当成通用的 goroutine 终止器。