最稳妥的 table-driven test 结构是用命名明确的 struct 定义测试数据，每个 case 通过 t.Run() 独立执行并确保 name 唯一可读，避免共享状态、未初始化指针和无效比较，同时控制日志与命名长度以保障可维护性。
怎么组织 table-driven test 的结构最稳妥
Go 里写表格驱动测试，核心不是“用 for 循环跑多个 case”，而是让每个测试用例能独立失败、错误信息可读、且不互相污染状态。最稳妥的方式是把测试数据定义为 []struct{}，每个字段名对应输入/期望/说明，而不是用 map 或 slice 混合类型。
- 用
struct{ name string; input int; want error; }而不是map[string]interface{}—— 编译期能检查字段存不存在，IDE 可跳转，重构安全 - 每个 case 的
name字段必须唯一且有意义，比如"returns_nil_for_empty_slice"，别写"case1"——t.Run()依赖它定位失败点 - 避免在 table 数据里放闭包或指针（比如
func() {}或&someVar）—— 测试并发执行时容易因变量复用导致误判 - 如果某个 case 需要 setup/teardown，不要塞进 table 结构体里，改用
func(t *testing.T) { ... }包裹逻辑，保持 table 干净
为什么 t.Run() 不能省，而且必须传 name 参数
t.Run() 不只是“加个子测试名”这么简单。它创建独立的 *testing.T 实例，让 t.Fatal、t.Skip、并发控制（t.Parallel()）都只作用于当前 case。漏掉它，所有 case 共享同一个 t，一个 t.Fatal 就直接终止整个测试函数，看不到其他 case 的结果。
- 必须传非空字符串给
t.Run()第一个参数 —— 空字符串会让go test -run=TestName/无法按前缀过滤子测试 - 如果
name含斜杠（/），会自动变成嵌套子测试层级，适合分组，比如"Parse/valid_input"和"Parse/invalid_format" - 别在循环外调用
t.Parallel()—— 它只对当前t生效，必须放在t.Run()的函数体内，否则无效
常见 panic：slice bounds out of range 或 nil pointer dereference
这类错误几乎都来自 table 数据本身没校验，或者 case 里忘了初始化依赖对象。Go 的表格驱动测试不提供自动防御，得靠你提前兜底。
- 如果 table 里有
input []string，但某个 case 写成input: nil，而被测函数没处理 nil，就会 panic —— 建议在 table 定义后加断言：if tc.input == nil { tc.input = []string{} } - 如果被测函数接收指针（如
*Config），table 里却传了nil，又没在测试里显式检查 “should panic”，就容易漏掉崩溃 —— 显式用defer func() { if r := recover(); r != nil { ... } }()捕获 - 用
reflect.DeepEqual比较结构体时，注意字段含func、unsafe.Pointer或未导出字段会 panic —— 改用自定义比较逻辑，或用cmp.Equal（需引入 golang.org/x/exp/cmp）
性能陷阱：log 输出太多 or 子测试命名太长
表格驱动测试跑几百个 case 很常见，但默认 go test -v 会为每个 t.Run() 打印一行 “=== RUN TestXxx/xxx”，如果 name 字段动辄 50 字符，终端刷屏根本没法扫视失败项；更隐蔽的是，大量 t.Log() 会拖慢测试速度，尤其 CI 环境。
立即学习“go语言免费学习笔记（深入）”；
- 限制
name长度在 32 字符内，用下划线代替空格，比如"empty_input_returns_error"而非"when the input slice is empty, it should return an error" - 只在失败时输出调试信息：用
if !cmp.Equal(got, tc.want) { t.Logf("got %+v, want %+v", got, tc.want) }，别无脑t.Log - 如果某个 case 初始化代价高（比如启动 mock HTTP server），考虑用
init()函数或包级变量缓存，但要注意并发安全 ——sync.Once是最轻量的选择
