go test -timeout 是进程级总耗时限制，超时则强制终止整个测试进程；它不控制单个Test函数或t.Run子测试，需手动用context.WithTimeout等实现细粒度超时。
go test -timeout 是进程级“大闸门”，不是单测函数超时
VSCode 里点运行测试按钮，背后调用的仍是 go test 命令，默认有 10 分钟总耗时限制。这个 -timeout 参数控制的是整个命令生命周期，超时就直接 kill 进程，不会等某个测试函数自己结束。
它不作用于 t.Run() 子测试，也不影响并发测试内部逻辑——你不能靠它给每个用例设 5 秒超时。想约束子测试，得手动加 context.WithTimeout 或封装 select + time.After 到测试逻辑里。
-
-timeout必须带单位，比如go test -timeout 30s，只写数字会报错time missing unit in duration - Go 1.22+ 支持复合单位（如
5m30s），旧版本建议统一用s或m - VS Code Go 扩展可能缓存上次参数，改了
-timeout没生效？试试重启集成终端或删掉.vscode/settings.json里的测试相关配置
VSCode 无法自动启用 -race，必须显式传参
VSCode 本身不检测竞态条件，Delve 调试器也不分析内存访问顺序——它只记录栈帧和变量当前值，看不到“谁刚写完又被覆盖”这种过程。断点停不下来，WATCH 面板也标不出共享变量被谁改过。
真正能暴露 data race 的唯一方式，是让 Go 工具链在编译期注入检测逻辑：必须用 go run -race 或 go test -race 启动。
- 在集成终端里直接运行
go test -race ./...，出问题立刻打印堆栈和 goroutine 交叉访问路径 - 想在 VSCode 调试中结合 race 检测？
launch.json里加"args": ["-race"]，但注意：这只对"mode": "test"有效；"mode": "exec"或"mode": "auto"下dlv exec不认这个参数 -
-race会带来 2–10 倍运行开销和 2–5 倍内存占用，严禁在生产环境启用
表驱动测试里跑单个用例，别靠手动改 tests 切片
标准 go test -run TestXXX 会执行整个函数体，包括所有 for _, tt := range tests 里的用例。调试第 37 个失败项时，临时删其他用例或加 t.Skip() 容易漏改、难复现。
推荐装 mrtnmch/vscode-go-table-driven-tests 扩展：它会在每个 t.Run() 上方自动加 “Run” 和 “Debug” CodeLens 按钮，点击即运行/调试该子测试，无需改代码、不依赖命名规范。
- 它只识别标准 Go 表驱动模式：
for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { ... }) } - 不兼容自定义循环结构（比如用
range索引再取值）、也不处理嵌套t.Run() - 扩展本身不改
go test行为，只是帮你生成带-run正则的命令，例如go test -run '^TestXXX/subtest_name$'
CI 和本地测试的 timeout 设置要分层考虑
CI 流水线里光靠 go test -timeout 20m 不够稳——如果测试进程卡死没退出，它不会触发；得配合平台级 timeout（如 GitHub Actions 的 timeout-minutes）做双重保险。
本地开发时，HTTP 接口类测试常需要验证超时行为本身，这时重点不是命令超时，而是客户端请求超时是否按预期触发 context.DeadlineExceeded 错误，且不泄露 goroutine。
- 用
httptest.Server模拟延迟服务，别直接连真实后端 - 记得
defer server.Close()，否则端口被占会导致后续测试失败 - 别混淆三者：命令级
-timeout、HTTP 客户端Timeout字段、以及测试逻辑里手动控制的子测试超时
go test 的语义边界和 Delve 的能力边界。 
