表驱动测试是go中通过[]Struct{}定义测试用例集合并遍历执行的惯用模式，核心是将输入、期望输出、错误条件等声明为结构体字段，确保每个case独立、可断言、易维护。
什么是表驱动测试：用 slice 模拟测试用例集合
Go 语言本身不提供内置的参数化测试语法，但通过 []struct{} 定义一组测试数据，配合 for 循环遍历执行，就是事实标准的「表驱动测试」。它不是框架或语法糖，而是一种被广泛接受的组织方式——核心是把输入、预期输出、甚至错误条件都提前声明为结构体切片。
常见错误是把逻辑判断塞进测试循环里（比如 if tc.input == "xxx" { ... }），这会让测试难以维护。正确做法是每个 struct 字段都对应一个可断言的维度：输入、期望返回值、是否应 panic、是否应返回 Error 等。
示例结构体定义：
tests := []struct { name String input string want int wantErr bool }{ {"empty", "", 0, true}, {"valid", "123", 123, false}, {"invalid", "abc", 0, true}, }如何写可读又健壮的 test case 结构体字段
字段命名直接影响后期维护成本。避免用模糊名如 val 或 res，优先使用与被测函数签名一致的名称（如函数接收 url string，测试字段就叫 url）；输出类字段统一用 want 开头（wantResult、wantStatusCode），而不是 expected 或 should——Go 标准库测试也这么写，工具链和 ide 更友好。
立即学习“go语言免费学习笔记（深入）”；
容易忽略的关键点：
-
name字段必须唯一且有信息量，推荐格式："，例如_ _ " "ParseDuration_short_form_ms"，避免只写"case1" - 如果被测函数可能 panic，不要只靠
recover()判断，应在结构体中显式加wantPanic bool字段，并在循环中用defer+recover()捕获后比对 - 涉及浮点数比较时，
want不要直接存float64，改用wantFloat+tolerance两个字段，避免精度导致测试偶然失败
如何处理 setup/teardown 与共享资源
表驱动测试强调「每个 case 独立」，但实际中常需复用初始化逻辑（如打开临时文件、启动 mock http server）。错误做法是在循环外做一次 setup，然后所有 case 共享状态——这会导致 case 间污染，尤其并行测试（t.Parallel()）下必出问题。
正确策略分三层：
- 纯内存操作（如字符串解析）：无需 setup，直接跑
- 单次初始化 + 隔离使用：用
t.Cleanup()注册清理动作，每个 case 自己调用setup()获取独立实例（如tempDir := t.TempDir()） - 外部依赖（DB、HTTP）：用
testify/suite或自建 struct 嵌入*testing.T，把 setup/teardown 放在 struct 方法中，但依然保证每个 case 调用自己的一套资源
特别注意：t.Parallel() 必须在循环体内、setup() 之后立即调用，否则 Go 测试运行器无法正确调度。
为什么 benchmark 不适合表驱动写法
go test -bench 的本质是反复调用同一函数并统计耗时，而表驱动测试的循环结构会把多个 case 合并在一次 BenchmarkXxx 函数中执行，导致结果混杂、无法区分各 case 性能。更严重的是，Go 的 benchmark 运行器要求函数体以 b.N 控制迭代次数，若你在循环里手动写 for i := 0; i ，就破坏了基准测试的采样逻辑。
真实需求场景下，应该：
- 为每个需压测的输入单独写一个
BenchmarkXxx_yyY()函数（如BenchmarkParsejsON_Valid、BenchmarkParsejson_Malformed） - 若输入组合多，用代码生成工具（如
go:generate+text/template）批量产出 benchmark 函数，而非运行时循环 - 需要对比不同实现？用
benchstat工具对多次go test -bench输出做统计分析，而不是塞进一张表里跑
表驱动的本质是提升「正确性验证」效率，不是性能测量手段。混淆这两者，会在 CI 中埋下隐性瓶颈。