t.Cleanup必须在测试函数内注册，因其生命周期严格绑定单个*testing.T实例，TestMain无测试上下文、顶层defer延迟至整个函数结束，均无法保障子测试级资源及时隔离清理。
t.Cleanup 是测试资源自动回收的可靠机制，但必须在测试函数内注册、绑定到当前 *testing.T 实例，且闭包变量不捕获循环变量——否则清理会失效或误操作。
为什么 t.Cleanup 不能写在 TestMain 或顶层 defer 里
t.Cleanup 的生命周期严格绑定单个 *testing.T 实例：它只对当前测试（包括其子测试 t.Run）生效，且在该测试返回前按后进先出顺序执行。写在 TestMain 里就脱离了测试上下文，框架根本不会调用；写在顶层 defer 里则属于测试函数作用域，等整个 TestXxx 返回才触发，子测试早已结束，资源可能已被复用或污染。
-
TestMain适合一次性的全局初始化（如启动容器），但无法感知单个测试成败，也不该用来清理子测试资源 -
defer在外层函数退出时才执行，t.Run中的defer会拖到所有子测试跑完才运行，容易删错目录、关错端口 -
t.Cleanup在每个子测试结束时立刻触发，哪怕t.Fatal或 panic 也照常执行
t.Cleanup 注册时闭包变量捕获的坑怎么避
这是最常翻车的地方：在循环中直接引用循环变量，导致所有清理函数看到的都是最后一次迭代的值。这不是 Go 测试特有，而是闭包语义本身的问题，但在测试里后果更隐蔽——比如本该删 5 个临时文件，结果全删了第 5 个。
- ❌ 错误写法：
for _, name := range files { t.Cleanup(func() { os.Remove(name) }) }→ 全部删files[len(files)-1] - ✅ 正确写法 1：
for _, name := range files { name := name; t.Cleanup(func() { os.Remove(name) }) } - ✅ 正确写法 2：
for _, name := range files { t.Cleanup(func(n string) { os.Remove(n) }(name)) }
哪些资源必须用 t.Cleanup，哪些没必要
t.Cleanup 的价值在于隔离「外部状态」：只要改动了磁盘、网络、进程环境、全局变量、mock controller 这类跨测试可见的东西，就必须用它。纯内存结构重置、局部变量清空，直接写在测试末尾更直观，也方便调试。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
- 必须用：
t.TempDir()创建的目录、net.Listen()占用的端口、gomock.NewController(t)创建的 mock 控制器（它内部已自动注册t.Cleanup）、临时写入的配置文件 - 不必用：重置一个
map[string]int、清空切片、重新赋值 struct 字段——这些没有副作用，也不影响其他测试 - 注意：
t.Cleanup函数里不能t.Fatal或t.FailNow，出错只能t.Log，否则会干扰原测试结果判定
t.Cleanup 和 defer / TestMain 混用时的典型冲突
常见错误是“多层清理叠加”：比如在 TestMain 启了一个 mock HTTP server，又在每个子测试里用 t.Cleanup 去关它。结果可能是 server 被重复关闭（报错），或者某个子测试关早了，后续测试连不上。
- 原则：全局资源（一次初始化、全程复用）走
TestMain+ 手动清理；单测独占资源（每次新建、用完即弃）走t.Cleanup - GoMock 是个好例子：调用
gomock.NewController(t)时，它检测到t有Cleanup方法，就自动注册了ctrl.Finish()，你完全不用再写defer ctrl.Finish() - 如果真要混用，确保清理动作幂等，或加锁/标志位防止重复操作
真正难的不是记住语法，而是在写测试时下意识判断：这个资源是否会被下一个测试看到？它的生命周期是否和当前 *testing.T 一致？一旦模糊，就容易掉进清理时机或作用域的坑里。
