Go测试要求_test.go文件与被测代码同包同目录，命名须为*_test.go，集成测试用// +build integration标记，复用辅助函数应放internal/testutil/，测试数据存testdata/目录。
测试文件必须和被测代码在同一包内
Go 的测试机制要求 xxx_test.go 文件和它要测试的源码在同一个包（package）下，不能跨包导入后测试。这是 Go 测试模型的基础约束，不是约定而是强制规则。
常见错误是新建一个 test/ 目录，把所有测试放进去并声明为 package test —— 这会导致测试无法访问未导出的函数、字段或变量，也根本不会被 go test 识别为当前包的测试。
- ✅ 正确做法：测试文件和源文件放在同一目录，包名保持一致（如都是
package main或package utils） - ❌ 错误做法：把
utils_test.go移到test/utils/下并改包名为package test - ⚠️ 注意：即使函数是导出的（首字母大写），跨包测试也无法覆盖内部逻辑分支、私有辅助函数、未导出字段等，丧失测试完整性
_test.go 文件命名与 go test 扫描逻辑
go test 默认只扫描以 _test.go 结尾的文件，并且会跳过 package main 中含 func main() 的测试文件（除非用 -c 构建）。但更关键的是：它按「包」而非「文件」执行测试，所以同目录下多个 _test.go 全部参与构建。
- 命名必须严格匹配
*_test.go，test_utils.go或utils.test.go都不会被识别 - 可拆分测试：比如
http_handler_test.go测接口，http_client_test.go测调用方，只要都在http/目录且包名一致即可 - 如果想临时禁用某个测试文件，加
// +build ignore在文件顶部（需配合go test -tags=ignore），但更推荐用t.Skip()控制单个测试函数
集成测试和单元测试是否需要分目录？
Go 官方不强制分离，但中大型项目普遍采用 internal/testutil + 标签控制的方式区分层级。真正的分界点不在目录，而在测试行为本身：是否依赖外部系统（DB、HTTP 服务、文件系统）。
立即学习“go语言免费学习笔记（深入）”；
- 纯内存计算、无副作用的测试 → 放在主包目录，用默认构建标签
- 需启动 Redis、读写磁盘、发起真实 HTTP 请求的测试 → 建议用
// +build integration标记，并在文件名保留_test.go，例如storage_integration_test.go - 运行时通过
go test -tags=integration显式启用，避免 CI 每次都跑慢速测试 - 不要新建
integration/子目录再放package integration—— 这会让测试无法访问原包私有成员，得不偿失
如何组织大量测试数据和辅助函数？
测试逻辑变复杂后，重复造 fixture 或硬编码 JSON 很容易失控。Go 推荐将复用型测试辅助内容放在 testutil 子包里，但要注意导入路径和循环依赖风险。
- 在项目根目录下建
internal/testutil/，包名为testutil，仅被测试文件导入（禁止业务代码 import） - 提供通用断言函数：
testutil.Equals(t, got, want)、testutil.JSONEq(t, got, want) - 测试数据建议放在
testdata/目录（非 Go 包），用filepath.Join("testdata", "config.json")加载，go test会自动包含该目录 - 避免在
testutil里引用主业务包，否则可能引发 import cycle；如有必要，用函数参数传入类型，而非直接 import
package testutil
import "testing"
func Equals(t *testing.T, got, want interface{}) {
if got != want {
t.Fatalf("got %v, want %v", got, want)
}
}
最常被忽略的一点：测试文件里的 init() 函数会在每个测试前执行，但不同 _test.go 文件之间的执行顺序不保证。别在 init() 里做带状态的初始化（比如启动全局 mock server），应该用 TestMain 或每个测试函数内独立 setup/teardown。
