Go单元测试和压力测试是上线前必过关口：单元测试须遵守_test.go命名、Test开头、*testing.T参数、同包四大规则；压力测试需关注goroutine泄露、连接复用及链路对齐；覆盖率重在错误路径覆盖而非数字高低。
Go 后端项目里，单元测试和压力测试不是“可选项”，而是上线前必须过的一关。没覆盖核心路径的单元测试，改一行就可能崩；没压测过的接口，在流量高峰时大概率超时或 OOM。这两类测试目标不同、手段不同、陷阱也不同，混着用反而容易漏掉关键问题。
go test -v 跑不通？先确认这四个硬性规则
很多新手卡在“测试不执行”或“函数找不到”，其实根本不是逻辑问题，而是违反了 Go 测试的命名与结构约定：
- 测试文件名必须以
_test.go结尾（比如user_service_test.go），不能是test_user.go或user_test.xyz - 测试函数必须以
Test开头，且首字母大写（TestCreateUser✅，testCreateUser❌） - 函数签名必须是
func TestXxx(t *testing.T)，参数类型不能是*testing.B（那是基准测试）或自定义结构体 - 测试文件和被测代码必须在同一个包下（除非你明确用了
xxx_test包做白盒测试，但普通业务不推荐）
常见错误现象：no test files —— 检查文件后缀；undefined: Add —— 检查是否在同包、是否导出（小写首字母函数无法被同包外的测试调用，但同包内可以）。
表驱动测试（table-driven tests）怎么写才不翻车
比起为每个 case 写一个 TestXxx 函数，用结构体切片 + t.Run 是 Go 社区事实标准。但它容易写成“看起来覆盖全、实际漏边界”的样子：
立即学习“go语言免费学习笔记（深入）”；
- 每个
case的name字段要能直接读出场景，比如"returns_error_on_empty_email"，而不是"case1" - 输入和预期必须显式写出，别在循环里动态算
expected（比如tt.a + tt.b），否则失败时看不出哪步错了 - 必须包含至少一个“非法输入”case：空字符串、负数 ID、
nil指针、超长字段——这些才是线上最常触发 panic 的点 - 复杂返回值（如 struct、map）别用
==直接比，优先用reflect.DeepEqual，但更推荐只比关键字段（比如只验err == nil和user.ID > 0）
示例中容易忽略的细节：t.Run 内部的闭包会捕获循环变量，必须用 tc := tc 显式复制，否则所有子测试跑的都是最后一个 case 的数据。
压力测试别只看 QPS，得盯住 goroutine 泄露和连接复用
go test -bench=. 是基准测试，不是压力测试；真正模拟线上并发要用独立工具（如 go-wrk）或自己写的压测脚本。但很多人一上来就调高 -c（并发数），结果本地跑着跑着内存飙到 8GB+，服务直接被系统 kill：
- HTTP 客户端必须复用
&http.Client{Transport: &http.Transport{...}}，否则每次请求都新建 TCP 连接，短时间大量TIME_WAIT会耗尽端口 - goroutine 数量要受控：用
semaphore := make(chan struct{}, maxConcurrent)或sync.WaitGroup配合context.WithTimeout，避免无限 spawn - 压测时关闭日志（
log.SetOutput(io.Discard)）、禁用 debug 接口，否则日志 IO 成瓶颈 - 观察指标不只是 QPS 和平均延迟，更要盯
runtime.NumGoroutine()是否持续上涨（泄露信号），以及http.DefaultClient.Transport.IdleConnTimeout是否设得太长
真实踩坑点：某次压测发现 P99 延迟突增，排查发现是数据库连接池满，但压测脚本没打任何 DB 相关指标——压测必须和业务链路对齐，只压 HTTP 入口没意义。
覆盖率报告里的“绿色”不等于安全
go test -coverprofile=coverage.out && go tool cover -html=coverage.out 生成的 HTML 看起来很美，但行覆盖率 95% 可能只覆盖了 happy path。真正危险的是那些“永远不执行”的分支：
- 错误处理分支（
if err != nil { return err }）往往没 mock 错误场景，结果整块逻辑裸奔 - 超时控制（
ctx.Done()分支）在单元测试里很难触发，得用context.WithDeadline注入过去的时间 - 第三方 SDK 的回调、异步通知、定时任务触发点，静态扫描根本看不到执行流
与其追求 100% 行覆盖，不如确保每个 if/else、每个 switch case、每个 error 返回路径都有对应测试 case。有些逻辑（比如分布式锁争抢失败重试）必须靠集成测试补位，单靠单元测试覆盖不了。
