Go test 命令原生支持单元测试，无需额外框架；需满足文件名规范（xxx_test.go）、含Test开头函数、与被测代码同包；集成测试需手动管理依赖生命周期，推荐用TestMain统一初始化并显式清理资源。
Go test 命令默认就支持单元测试，无需额外“搭建环境”
很多人误以为 Go 需要像 Java 那样配 Maven、JUnit 或 Python 那样装 pytest 才能测——其实 go test 是 Go 工具链原生命令，只要项目结构合规（xxx_test.go 文件放在包目录下），直接运行就能跑。不需要安装第三方测试框架，也不用写 main 函数或启动服务。
常见错误现象：go test 报 no buildable Go source files，通常是因为：
-
*_test.go文件里没定义任何以Test开头的函数（如func TestAdd(t *testing.T)） - 文件名拼错，比如写成
test_add.go（缺下划线）或add_test.g0（拼写错误） - 测试文件和被测代码不在同一包，且没用
import正确引入（Go 要求测试文件和源码在同一个包，除非是外部集成测试）
集成测试需手动控制依赖生命周期，比如启动/关闭 mock 数据库
单元测试应隔离外部依赖；集成测试则要模拟真实协作场景，比如连接 SQLite 临时文件、起一个本地 HTTP server、或用 testcontainers-go 拉 PostgreSQL 容器。关键不是“怎么搭”，而是“谁负责启停”。
推荐做法：用 TestMain 统一管理共享资源，避免每个测试都重复初始化：
func TestMain(m *testing.M) {
db, _ := sql.Open("sqlite3", ":memory:")
defer db.Close()
// 设置全局测试 DB 实例
testDB = db
os.Exit(m.Run())
}
注意点：
-
TestMain不会自动继承子测试的*testing.T，不能在里面调用t.Fatal，出错要用os.Exit(1) - 如果用了容器（如
testcontainers-go），务必在defer或TestMain结尾显式container.Terminate()，否则 CI 环境可能堆积僵尸容器 - 不要在
init()函数里初始化数据库连接——它在TestMain之前执行，无法捕获 setup 失败
区分 -short 和 -race 标志的实际用途，别滥用
go test -short 不是“快速模式”，而是约定俗成的“跳过耗时测试”的开关；go test -race 是开启竞态检测，二者解决完全不同的问题。
