go test -timeout 是进程级总耗时限制，超时则强制终止整个测试进程，不控制单个 Test 函数或 t.Run 子测试；VSCode 中需显式配置 "go.testTimeout": "15m" 或手动执行 go test -timeout 20m ./...。
go test -timeout 是进程级总耗时限制，不是单测超时
VSCode 点“运行测试”按钮后卡住或报 timeout，往往不是某个 TestXXX 函数跑太久，而是整个 go test 进程被掐断了。默认 10 分钟（600 秒）一到，进程直接 kill，不会等当前测试函数结束。
常见现象包括：
- 测试日志突然中断，没输出 PASS/FAIL，终端显示
signal: killed或直接退出 - 明明单个用例只跑几秒，但整个套件含 50+ 用例时频繁超时
- 加了
t.Log或fmt.Println后反而更容易超时——因为 I/O 缓冲或调试输出拖慢整体节奏
解决方法：
- 在 VSCode 的
.vscode/settings.json中显式配置超时值，例如："go.testTimeout": "15m" - 或在集成终端手动运行：
go test -timeout 20m ./...（注意单位必须带m或s） - 避免在
init()或TestMain中做重 IO、网络请求或未设限的循环——它们计入总耗时
VSCode Go 扩展不自动传 -race，必须手动启用
想靠 VSCode 点一下就触发竞态检测？不行。-race 不是默认开关，也不受插件 UI 控制。它必须作为参数透传给 go test，否则 Delve 和 OmniSharp 都看不到数据竞争。
典型误操作：
- 只在
launch.json里加"args": ["-race"]，但"mode"是"exec"—— 这个参数会被忽略 - 改了设置没重启集成终端，VSCode Go 扩展仍缓存旧参数
- 在非
test模式下（比如直接go run main.go）加-race，报错flag provided but not defined
正确做法：
- 仅对
"mode": "test"的launch.json配置生效："args": ["-race", "-timeout", "30s"] - 或统一在终端执行：
go test -race -timeout 30s ./... - 注意
-race会显著拖慢执行（2–10 倍）和吃内存，别在 CI 或日常全量跑时默认开启
表驱动测试中单个子测试失败，别靠删代码临时调试
面对一个含几十个 t.Run() 的表驱动测试，第 23 个用例失败，你是不是习惯注释掉其他用例、改 for 循环范围、或者加 t.Skip()？这些操作极易漏恢复、难复现，还污染 git diff。
更稳的方式是利用工具链本身的能力：
- 装
mrtnmch.vscode-go-table-driven-tests插件，它会在每个t.Run(tt.name, ...)上方注入 “Run” 和 “Debug” CodeLens 按钮 - 点击即可生成精准命令：
go test -run '^TestXXX/subtest_name$' -v，不改源码、不依赖命名规则 - 该插件只识别标准结构：必须是
for _, tt := range tests { t.Run(...)，自定义索引取值或嵌套t.Run()不支持
插件自身启动慢，会拖垮整个测试流程
VSCode 的 Go 插件（golang.go）如果激活时间超过 1 秒，就会让“运行测试”按钮迟迟不响应，甚至导致测试命令根本没发出去。这不是测试代码的问题，是插件卡在初始化阶段。
验证方式：
- 按
Ctrl+Shift+P运行Developer: Show Running Extensions - 找
golang.go对应行，看Activation Time (ms)是否 > 1000，Status是否为空或Activation failed
常见诱因：
- 工作区根目录下有巨型
vendor/或node_modules/，插件扫描时阻塞 -
go.mod依赖太多，gopls加载类型信息缓慢 - 本地
GOROOT或GOBIN路径配置错误，插件反复尝试失败
临时缓解：
- 关闭无关文件夹，用轻量工作区单独开测试目录
- 在
settings.json中加："go.goplsArgs": ["-rpc.trace"]，再看输出面板定位卡点
真正麻烦的是插件静默卡住：不报错、不崩溃、但永远不 Ready。这种状态下，VSCode 测试按钮可能灰掉、右键菜单无反应，而控制台却一片安静——必须靠 Show Running Extensions 主动揪出来。
