t.run 是 go 单元测试的基础设施，解决表驱动测试中错误定位模糊、用例隔离差等问题；它为每个用例创建独立 *testing.t 实例，支持精确失败定位、单独运行、并发执行，并需配合 t.helper() 优化错误行号。
Go 原生的 t.Run 子测试（subtests）不是“可选技巧”，而是组织可靠单元测试的基础设施——它直接解决表驱动测试中错误定位模糊、用例隔离差、调试成本高的问题。
为什么必须用 t.Run 而不是裸循环
裸循环跑多个断言，一旦某个用例失败，t.Errorf 会继续执行后续用例，但错误堆栈指向循环体内部，无法知道是哪组输入出错；且所有用例共享同一测试上下文，setup/teardown 逻辑容易互相污染。
-
t.Run为每个用例创建独立的*testing.T实例，失败时输出精确到子测试名（如TestAdd/负数相加） - 子测试可单独运行：
go test -run TestAdd/含零，调试时不用重跑全部用例 - 调用
t.Parallel()后，不同子测试可并发执行（注意：共享状态的测试不能并行） - 变量捕获常见坑：循环中直接用
tt闭包会捕获最后一次迭代值，必须用局部变量拷贝：tt := tt
t.Helper() 怎么让错误信息指向真实调用行
把重复断言抽成辅助函数（比如 assertEqual）很自然，但默认错误行号会显示在辅助函数内部，而不是测试里调用它的地方——这会让调试多绕两步。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 在辅助函数第一行加
t.Helper()，就能让t.Errorf的栈追踪跳过该函数，直接标出测试文件中哪一行调用了它 - 不加
t.Helper()时，错误提示类似helper.go:12；加了之后变成math_test.go:45 -
t.Helper()不影响测试逻辑，只改错误报告路径，没理由不用
表驱动测试 + t.Run 的最小可行结构
这不是“推荐写法”，而是 Go 社区事实标准。结构松散或硬编码 if 分支的测试，基本等于没测。
- 用
map[string]struct{...}或[]struct{...}定义测试集，字段名要语义清晰（a,b,expected比input1,input2,out更易维护） - 子测试名用
name字段，别拼字符串："a=2,b=3,expected=5"不如"正数相加" - 每个子测试函数体内只做一件事：调用被测函数 + 断言，避免嵌套逻辑
- 边界用例必须显式列出：空值、零值、负数、极大值、nil 指针等，不能靠“大概覆盖了”蒙混
Subtests 在 TDD 流程里的真实作用点
TDD 的“红-绿-重构”循环里，子测试不是锦上添花，而是让“红”阶段可预期、“绿”阶段可验证、“重构”阶段敢动手的关键。
- 写第一个失败测试时，就该用
t.Run框出未来所有用例的骨架，哪怕只填一个{"基础场景", 1, 1, 2} - 实现函数过程中，新增用例只需往表里追加结构体，不用动测试逻辑，TDD 节奏不会被打断
- 重构接口或参数时，所有子测试会立刻报错，告诉你哪些调用点要同步改——这是裸循环做不到的反馈密度
- CI 中
go test -coverprofile统计的覆盖率，是按子测试粒度聚合的，没t.Run就难判断哪个分支真没覆盖
子测试本身没有魔法，但它强制你把“测试意图”提前具象化。最容易被忽略的不是语法，而是：每个 t.Run 名字是否真的表达了业务含义，而不是技术细节；每个用例是否独立可验证，而不是靠前后顺序隐含依赖。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
