go test 识别测试文件需满足：文件名以 _test.go 结尾，且包声明为同包（如 package cache）或独立 _test 包（如 package cache_test），不可置于 internal/、vendor/ 或 testdata/ 目录。
同包测试文件命名和位置怎么写才被 go test 识别
Go 的 go test 只认两种模式：要么测试文件和被测代码在同一个包（xxx_test.go，包声明为 package xxx），要么拆成独立的 _test 包（xxx_test.go，包声明为 package xxx_test）。前者是默认推荐方式，后者只在特定场景下有用。
常见错误现象：go test 报 no test files，其实是文件名没带 _test.go 后缀，或者放在了 testdata/ 这类被忽略的目录里；又或者包名写成了 package main 或 package test —— Go 要求测试文件的包名必须和被测源码一致（同包）或以 _test 结尾（独立包）。
- 测试文件必须以
_test.go结尾，比如http_client_test.go - 同包测试时，
package声明必须和源码文件完全一致，比如源码是package cache，测试文件也得是package cache - 不要把测试文件放进
internal/或vendor/下——go test默认不扫描这些路径
什么时候该用 package xxx_test 独立包
独立 _test 包不是为了“隔离”，而是为了绕过 Go 的导出限制：它能访问被测包中未导出的标识符（函数、字段、类型），但前提是被测包本身允许——即被测包必须启用 go:build ignore 以外的构建约束，且不能是 main 包。
典型使用场景：想对一个私有 helper 函数做白盒测试，但它没导出，同包测试又因为循环 import 或测试逻辑太重而难以组织。这时建个 cache_test.go，包声明为 package cache_test，就能直接调用 cache.unexportedHelper()。
立即学习“go语言免费学习笔记（深入）”；
- 仅适用于非
main包；main包无法被其他包 import，_test包自然也无法引用 - 需要在测试文件顶部加
//go:build unit（或类似）并确保构建 tag 不冲突，否则可能被跳过 - 性能无差异，但可读性下降——读者要跨两个包理解逻辑，IDE 跳转也多一层
同包测试里怎么避免循环 import 和测试污染
同包测试最常踩的坑，是测试文件里误引入了本不该依赖的模块，导致被测包的 import 图变重，甚至引发循环 import。比如在 cache/ 包的测试里 import 了 database/sql，而 cache 本身并不依赖它——这会让所有 import cache 的用户间接带上数据库驱动。
根本原则：测试代码的 import 列表，应该只包含被测逻辑实际依赖的包 + 测试专用辅助（如 testify/assert）。如果发现测试里用了大量外部 SDK 或框架，说明被测代码职责过重，或者测试粒度太粗。
- 别在测试里初始化全局状态（如
http.DefaultClient = ...），它会污染其他测试；用局部变量或httptest.Server替代 - 避免在
init()函数里做任何副作用操作——测试并行执行时行为不可控 - 如果测试需要 mock，优先用接口+依赖注入，而不是 patch 全局变量或函数（Go 没原生支持，硬 patch 易错且难维护）
go test -run 和 -bench 在不同包结构下的行为差异
同包测试和 _test 包对 go test 命令的行为影响不大，但有一个关键点：当使用 -run 或 -bench 指定子测试名时，Go 是按函数名匹配的，不关心包名。不过，如果你在 xxx_test.go 里写了多个 TestXxx 函数，它们都属于同一个测试二进制，所以 go test -run=TestCacheHit 会跑所有匹配的函数，无论它们物理上在哪个文件。
容易被忽略的是 go test ./... 的递归行为：它会进入每个子目录，只要该目录下有 *_test.go 文件且包名合法，就尝试编译测试。这意味着，如果你在 cmd/myapp/ 下放了个 main_test.go（包名 package main），go test ./... 会失败，因为 main 包不能被 import。
-
go test -c生成的测试二进制，只包含当前目录下匹配的测试文件，不会自动合并跨目录的_test包 - 用
go test -v时，输出里的测试函数前缀是包名，比如cache.TestGetvscache_test.TestGet，这是区分两者最直观的方式 - CI 中若用
go test ./...，务必确认没有遗留的main_test.go或错误包名的测试文件，否则整个命令会中断
真正麻烦的从来不是选哪种结构，而是测试文件里悄悄改了全局变量、复用了未清理的临时目录、或者用 time.Now() 做断言——这些和包组织无关，但会让测试在本地通过、CI 失败、别人拉下来就挂。
