Go单元测试必须满足三个硬性条件：文件名以_test.go结尾、函数名以Test开头且后跟大写字母、唯一参数为*testing.T类型；否则go test直接跳过，不报错也不提示。
Go 的单元测试和基准测试不是“写完再补”，而是从函数签名定下来那一刻就该同步设计——否则很容易写出无法覆盖边界、无法隔离依赖、或性能毛刺被掩盖的测试。
Test 函数必须满足的三个硬性条件
Go 测试框架靠反射自动发现测试函数，但只要漏掉任意一条，go test 就会直接跳过它，不报错也不提示：
- 文件名必须以
_test.go结尾（比如math_test.go，不能是math_test.go.bak） - 函数名必须以
Test开头，且紧随其后的字符必须是大写字母（TestAdd✅，testAdd❌，Testadd❌） - 唯一参数类型必须是
*testing.T（不能是testing.T值类型，也不能多加其他参数）
常见错误现象：go test 输出 ok ./math 0.001s 但没跑任何用例——八成是函数名或文件名不合规。用 go test -v 能看到实际执行了哪些测试，是第一排查手段。
表驱动测试中 t.Run 的命名陷阱
子测试名（t.Run("xxx", ...) 中的字符串）不是随便起的，它直接影响 go test -run 过滤和失败定位：
立即学习“go语言免费学习笔记（深入）”；
- 名字里不能含斜杠
/，否则go test -run=TestAdd/positive会误判为路径匹配，可能漏掉本该运行的子测试 - 避免纯数字开头（如
"123"），某些 Go 版本解析时会与测试序号混淆 - 推荐用
fmt.Sprintf("%s_%d_%d", "Add", a, b)生成唯一可读名，而不是简单拼接a+b——负数会导致名字非法（如"-1+2"）
性能影响：每个 t.Run 创建新测试上下文，开销极小（纳秒级），但若在循环内无意义地嵌套多层 t.Run（比如对每个字段单独跑一个子测试），会拖慢 -v 输出解析，且让 go test -run=xxx 变得难写。
Benchmark 函数的 b.ResetTimer 时机问题
Benchmark 函数默认从函数入口开始计时，但初始化逻辑（如构造测试数据、预热缓存）不该计入性能结果——必须手动控制计时开关：
- 错误写法：
data := make([]int, 1000); for i := range data { data[i] = i }; b.ResetTimer(); for i := 0; i ——<code>make和初始化被计入耗时 - 正确顺序：所有 setup 放在
b.ResetTimer()之前；循环体只留待测逻辑 - 如果待测函数本身有明显 warm-up 需求（比如首次调用触发 JIT 或内存页分配），应在
b.ResetTimer()后加一次 dummy 调用，再开始主循环
容易踩的坑：b.N 不是固定次数，而是框架根据采样动态调整的——你不能假设它等于 100 万；所有依赖 b.N 的状态（如 slice 容量）必须在循环内重置，否则第二次运行时可能复用上次残留数据。
go test 命令组合的实际取舍
单个命令能解决大部分场景，但组合不当反而掩盖问题：
-
go test -bench=. -benchmem：必须一起用。-bench=.启动所有Benchmark，-benchmem才会输出内存分配统计（allocs/op 和 B/op）。单独用-benchmem无效 -
go test -race会显著拖慢执行（2–5 倍），且禁止与-bench同时使用——竞态检测和性能压测目标冲突，需分开执行 -
go test -coverprofile=c.out && go tool cover -html=c.out生成覆盖率报告时，注意-covermode=count（记录执行次数）比默认atomic更准，但更慢；对 CI 场景，-covermode=atomic足够
真正容易被忽略的是：go test 默认不递归进入子目录，想测整个模块得加 ./...（三个点），而不是 .。漏掉这个，internal/ 下的测试根本不会跑。
