不加 t.helper() 时错误行号定位在辅助函数内，因测试框架默认取最近调用 t.error 的栈帧；必须在辅助函数首行、t.error 前、每层嵌套都调用 t.helper() 才能正确回溯到测试用例行。
为什么 t.Helper() 不加就总定位到辅助函数内部
不加 t.Helper() 时，t.Errorf 报错行号永远钉死在辅助函数体内的那行——比如你写了 assertEqual，第 5 行调用 t.Errorf，失败就显示 xxx_test.go:5，哪怕真实出错的是测试文件第 88 行的 assertEqual(t, 1, 2)。这是因为测试框架默认取栈上最近一层调用了 t.Error* 的位置，而它看到的就是你的工具函数。
怎样正确调用 t.Helper() 才能让错误跳回测试用例
t.Helper() 必须满足三个硬性条件，缺一不可：
- 放在函数第一行（不能被
if、for或defer包裹） - 必须在任何
t.Error*或t.Fatal*调用之前 - 如果辅助函数嵌套多层（比如
assertEqual → deepEqual），每一层都得各自调一次t.Helper()
示例：
func assertEqual(t *testing.T, got, want interface{}) {
t.Helper() // ✅ 必须首行，且在 t.Errorf 前
if !reflect.DeepEqual(got, want) {
t.Errorf("got %+v, want %+v", got, want)
}
}
哪些函数该标 Helper，哪些不该
只对**纯测试复用逻辑**标记：t.Helper() 不是“让函数变辅助”，而是“告诉测试框架：这一层不参与失败决策，别停在这儿”。
- ✅ 应该标：自定义断言（
assertNoError）、数据构造（mustParseJSON）、环境预设（setupTestDB） - ❌ 不该标：含
t.Run的函数（子测试会重置 helper 状态）、含t.Cleanup但本身也做失败判断的函数、封装了t.Fatal且意图终止当前测试流程的函数
特别注意：如果一个函数既返回值又可能报错（如 mustOpenFile），只要它最终调用了 t.Fatalf，就必须标 t.Helper()，否则失败行号仍指向函数内部。
容易被忽略的兼容性与 IDE 联动陷阱
t.Helper() 自 Go 1.9 引入，老版本不会报错，但静默失效——你看到的仍是辅助函数内的行号，却查不出原因。更隐蔽的问题是：
- 跨包调用未导出的辅助函数时，某些 IDE（如 GoLand、VS Code）无法正确跳转到测试用例行
-
t.Log不受t.Helper()影响，日志行号始终显示在辅助函数内，这是设计使然，别试图绕过 - 并行测试中混用
t.Parallel()和未标t.Helper()的辅助函数，会导致错误定位混乱，让人误以为是并发 bug
最常被漏掉的一点：helper 不会自动透传。A 调 B，B 标了 t.Helper()，但 A 没标，失败就会卡在 A 的 t.Errorf 行，而不是测试函数里调用 A 的那行——每层都得自己负责声明。
