最常见原因是Test函数名未大写、签名不符或文件名不以_test.go结尾；需确保函数名首字母大写、签名严格为func TestXxx(t *testing.T)、文件名正确，且在包路径下执行命令。
go test -run 匹配不到测试函数的常见原因
最常遇到的情况是 go test -run TestFoo 执行后显示 ok . 0.001s 却没跑任何测试——不是命令错了，而是函数根本没被识别。
-
TestFoo函数名首字母必须大写，testfoo或testFoo都无效 - 函数签名必须严格为
func TestFoo(t *testing.T)，少一个星号、多一个参数、用*testing.B都不行 - 测试文件名必须以
_test.go结尾，test_foo.go或foo_test.txt不会被加载 - 执行命令时当前目录必须是待测包所在路径，或显式指定包路径如
go test ./internal/user -run TestLogin - 如果测试在子模块里且启用了
//go:build integration这类 build tag，需加-tags integration才能编译进去
正则匹配要防“误伤”和“漏网”
-run 的值是 Go 的 regexp 包解析的正则表达式，不是简单字符串包含匹配。默认行为容易导致多跑或不跑。
- 想只跑
TestLogin？用-run ^TestLogin$，否则TestLoginError和TestAutoLogin也会被拉进来 - 想排除
TestLegacy和TestExternalAPI？别直接写(?!...)否则会空匹配失败；改用-run ^Test(?!Legacy|ExternalAPI) - Windows 命令行下单引号会被吃掉，必须用双引号并转义美元符：
-run "^(Test(?!Legacy).*)$" - 不确定正则是否生效？先运行
go test -list .看当前包所有可识别的测试名，再构造表达式
-count 和 -race 叠加可能让测试“假失败”
调试随机失败或竞态问题时，习惯性加 -count=5 和 -race，但这两者合起来有隐藏副作用。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
-race本身会让单次运行慢 2–5 倍；-count=5是乘性放大，不是跑 5 次那么简单——它会在同一进程内连续初始化 race detector 5 次 - 若测试依赖全局状态（比如复用的
sync.Map、临时文件、HTTP server 端口），多次执行间可能互相污染，导致本不该失败的测试挂掉 - 真正需要验证稳定性时，用 shell 循环更干净：
for i in {1..5}; do go test -run TestCache; done - 加
-v能看到每轮执行的详细输出，避免因静默跳过而误判结果
测试文件位置和包可见性影响编译结果
Go 编译测试时不会把 _test.go 文件纳入主构建，但对「哪些测试能被看见」仍有严格限制。
- 测试文件必须和被测代码在同一个包（
package xxx声明一致），跨包调用私有函数无法测试，得暴露接口或用内部测试结构 - 放在
internal/下的测试文件，只能被同目录或子目录的包引用；外部包无法 import 它们，go test也找不到 - 如果测试文件里 import 了生产代码未声明的包（比如测试专用的
github.com/stretchr/testify），而该包没在go.mod中，go test会直接报错退出，而不是跳过 -
go test ./...会递归扫描所有子目录，但不会进入被//go:build ignore标记的目录，也不会处理 vendor 下的测试
测试函数是否被编译进二进制，取决于三件事：文件名规则、函数签名合规性、以及当前构建上下文是否把它纳入 scope——这三者缺一不可。最容易忽略的是 build tag 和模块路径的组合效应，尤其在多 module 项目中。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
