go test 是 go 测试统一入口，单元测试需隔离外部依赖、用接口注入内存实现，集成测试则真实连接外部服务；应通过子测试+testing.short()区分，避免覆盖率失真，注意文件同包、teardown 可靠性。
go test 是 Go 项目里跑单元测试和集成测试的统一入口，但“单元”和“集成”不是靠命令区分的，而是靠**测试代码怎么写、依赖怎么处理、运行环境怎么准备**来界定的。直接上结论：单元测试必须隔离外部依赖（数据库、HTTP、文件系统等），集成测试则要真实连接它们——混用会导致本地能过 CI 失败，或覆盖率虚高但线上崩。
TestXxx 函数里怎么判断是单元还是集成？
看它是否直接调用真实外部服务：
- 调用了
sql.Open、http.Get、os.Open或任何需要网络/磁盘/进程间通信的 API → 很可能已是集成测试 - 所有依赖都通过接口注入，且测试中传入的是内存实现（如
map模拟缓存、bytes.Buffer模拟 IO）→ 这是合格的单元测试 - 用了
testing.Short()做跳过判断，但没在go test -short下真正跳过耗时操作 → 表面像单元，实际拖慢 CI
如何让同一个_test.go 同时支持单元与集成验证？
用子测试 + 环境开关，避免拆成两个文件导致维护割裂：
- 在集成测试子函数开头加
if testing.Short() { t.Skip("skipping integration test") } - 单元测试子函数不依赖外部资源，始终运行；集成子函数只在
go test -short=false时执行 - 数据库连接字符串从环境变量读取，比如
os.Getenv("TEST_DB_URL")，空值则跳过集成部分 - 避免在
init()或包级变量里初始化连接，否则单元测试也会触发
go test -cover 为什么对集成测试意义不大？
覆盖率数字会失真，因为：
- 集成测试常走通路但只覆盖主干逻辑，大量错误分支（如网络超时、DB 连接拒绝）在本地难复现
-
go test -cover统计的是「行是否被执行」，而集成测试里大量代码（如重试逻辑、日志、监控上报）只有在故障场景才触发 - 若集成测试依赖真实 MySQL，
go tool cover无法追踪到驱动内部的 SQL 执行路径 - 真正该关注的是「关键路径是否被集成验证过」，而不是覆盖率百分比 —— 可以用注释标记：
// coverage: integration-only
容易被忽略的边界：测试文件命名与包可见性
Go 的测试机制对文件位置和符号可见性很敏感：
- 测试文件必须和被测代码同包（例如
user.go和user_test.go都在user包），否则无法访问未导出字段和函数 - 如果想测内部逻辑但又不想暴露给外部，别把测试文件放到
internal/外层包下 —— 否则go test ./...会报错找不到包 -
_test.go文件里不能 import 同名主包的别名（如import u "user"），会触发循环导入 - 表驱动测试中，
t.Run的 name 字符串里别含斜杠（/）或控制字符，否则go test -run过滤会失效
defer os.Remove 在 panic 时仍执行 —— 否则下次测试可能因残留文件失败。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
