最基础的测试运行方式是在项目根目录或含_test.go文件的包目录下执行go test，它自动查找_test.go文件中以Test开头、签名为func TestXxx(t *testing.T)的函数并执行；默认不显示通过详情，加-v可查看执行过程。
go test 命令怎么运行最基础的测试
直接在项目根目录（或含 _test.go 文件的包目录）下执行 go test，它会自动查找当前目录下所有以 _test.go 结尾的文件，运行其中以 Test 开头、签名为 func TestXxx(t *testing.T) 的函数。
常见错误现象：什么都没输出，或提示 no test files —— 检查文件名是否带 _test.go 后缀、函数名是否首字母大写且以 Test 开头、是否漏了 *testing.T 参数。
- 不加任何参数时，默认只运行测试，不显示通过详情（失败才会打印）
- 想看每条测试的执行过程，加
-v：go test -v - 测试文件里混有示例函数（
ExampleXxx）或基准测试（BenchmarkXxx），它们不会被go test默认执行
如何只运行某个特定测试函数
用 -run 参数配合正则匹配，例如运行 TestAdd： go test -run TestAdd；支持子串匹配，-run Add 也会命中 TestAdd 和 TestDataAdd。
注意 -run 是按函数名匹配，不是文件名；大小写敏感；如果函数名含斜杠（如 TestServer/Start），需转义或加引号：go test -run "TestServer/Start"。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 多个测试用竖线分隔：
go test -run "TestAdd|TestSub" - 排除某个测试可结合
^和$：go test -run "^(?!TestLegacy).*$"（慎用，易出错） - IDE（如 VS Code）点击测试函数旁的 ▶️ 实际也是调用带
-run的go test命令
为什么 go test -v 显示测试通过但程序没跑完
典型表现是 go test -v 打印了 PASS，但你确认测试函数里有 fmt.Println 或网络请求却没看到输出 —— 因为默认情况下，go test 会捕获并丢弃测试函数中的标准输出（os.Stdout），只在测试失败时才释放。
解决办法是加 -v 并确保没被其他 flag 抑制；更稳妥的是显式启用日志输出：go test -v -args -test.v=true 不起作用，正确方式是：
- 在测试代码中用
t.Log()或t.Logf()，它们始终可见（带-v时显示为普通日志，不带则仅失败时输出） - 强制不捕获 stdout：
go test -v -gcflags="-l" 2>&1 | grep -v "PASS\|FAIL"（不推荐，破坏测试隔离性） - 调试时临时加
os.Stdout = os.Stderr，但提交前必须删掉
go test 运行慢？检查是否误启用了 race 检测或 coverage
go test -race 或 go test -cover 会让编译和运行明显变慢，尤其在大型项目中。如果你只是想快速验证逻辑，别无故加这些 flag。
-race 会插桩所有内存访问，开销巨大；-cover 需要重编译并注入计数器，首次运行尤其慢。CI 中常用，本地开发时建议按需开启。
- 检查是否全局 alias 了
go test（比如 zshrc 里写了alias go=test -race） -
go test -coverprofile=coverage.out之后再go tool cover -html=coverage.out才能看覆盖率报告，单独-cover只打印汇总行 - 子测试（
t.Run）不影响go test行为，但嵌套过深可能让-run匹配变复杂
真正容易被忽略的是：测试文件里的 init() 函数会在所有测试开始前执行一次，且无法用 -run 过滤；如果有耗时初始化或副作用，它会拖慢整个测试套件，甚至导致并发测试出错。
