Go不支持直接运行单个_test.go文件，必须指定包路径；常用方式是进入文件所在目录后执行go test -run=^TestMyFunc$，或显式指定包如go test ./config -run=TestParseConfig。
直接运行单个 _test.go 文件
Go 不支持像 go test xxx_test.go 这样裸传文件路径来运行测试，必须指定包路径。如果你只改了一个测试文件，想快速验证，最常用的方式是进入该文件所在目录后运行：
go test -run=^TestMyFunc$其中
TestMyFunc 是你要跑的测试函数名；^ 和 $ 保证精确匹配，避免误中同前缀的其他测试（比如 TestMyFuncWithTimeout）。不加正则边界符容易白忙活。
指定测试文件所在的包并过滤函数
Go 的 go test 命令本质是按包执行的，不是按文件。即使你只写了一个 xxx_test.go，只要它和 xxx.go 在同一目录、同属一个包（比如 package main 或 package utils），就必须用包路径启动：
go test ./... -run=TestParseConfig注意：
-
./...表示当前目录及所有子目录下的包（慎用，可能触发无关包） - 更安全的是显式指定包路径：
go test ./config（假设测试文件在config/目录下） -
-run参数值不区分大小写，但建议严格按函数名写，避免因命名风格差异漏匹配
运行某个 _test.go 文件里的全部测试
Go 没有“仅加载某一个测试文件”的机制——只要属于同一个包，所有 *_test.go 都会被编译进测试二进制。但你可以靠命名约定+-run规避干扰：
go test -run=^TestIntegration|^TestUnit$如果把集成测试统一命名为
TestIntegrationXXX、单元测试为 TestUnitXXX，就能批量筛选。否则，别指望靠文件名控制执行范围；go test 看的是函数名和包，不是磁盘上的 .go 后缀文件。
常见错误：no buildable Go source files
这个错误通常出现在两种情况：
- 当前目录下没有
.go文件（只有_test.go），而测试文件又用了// +build ignore或build tag排除了当前环境 - 测试文件里 import 了当前包，但包名写成了
package main，而主源文件是package utils—— 包名不一致会导致测试无法识别主代码 - 使用了
go:build注释但没加空行，导致构建约束失效（Go 1.17+ 要求go:build后必须紧跟空行）
go list -f '{{.Name}}' .看输出是不是你预期的包名；再用 go list -f '{{.GoFiles}} {{.TestGoFiles}}' .确认哪些文件被纳入了当前包。
真正卡住人的往往不是语法，而是包路径和构建约束的隐式耦合——哪怕只动了一个测试文件，也要确保它和对应源码在同一个包、能被 go list 正确识别，否则 go test 根本不会启动。
