t.Helper()能让失败行号指向真实调用处，因为它告诉测试框架跳过该辅助函数的栈帧，将错误定位回上一层调用者；必须在t.Errorf前调用，且仅用于纯测试复用函数（如断言、setup），嵌套时每层需显式标记。
为什么 testing.T.Helper 能让失败行号指向真实调用处
Go 的测试失败默认显示的是 t.Errorf 所在的行号，而不是你写测试用例时调用封装函数的地方。这会导致你每次都要点进辅助函数里找哪一行触发了错误，尤其在封装了断言逻辑（比如 assertEqual）时特别痛苦。加 Helper() 告诉测试框架：“这一层是辅助的，别把失败堆栈停在这儿”，它就会跳过该函数，把错误位置回溯到上一层——也就是你真正写测试的那行。
怎样正确标记 helper 函数（不是所有函数都该标）
只在**纯粹用于测试逻辑复用、不包含独立测试行为**的函数里调用 t.Helper()。典型场景是封装断言、预设环境、构造测试数据等。如果函数本身会调用 t.Run 或执行 t.Fatal 等终止操作，就不该标为 helper，否则可能掩盖真正的失败入口。
- ✅ 应该标：自定义断言函数、
setupTestDB、mustParseJSON - ❌ 不该标：
runSubtestWithTimeout（内部用了t.Run）、teardownAll（含t.Cleanup但非纯辅助） - ⚠️ 注意：必须在任何
t.Error*或t.Fatal*之前调用t.Helper()，否则无效
t.Helper() 在嵌套调用链中的实际效果
假设你有三层调用：TestFoo → assertEqual → deepEqual，其中 deepEqual 是最终做比较并调用 t.Errorf 的函数。如果不标 helper，失败行号显示的是 deepEqual 里的 t.Errorf 行；如果只在 assertEqual 里加 t.Helper()，失败会定位到 TestFoo 中调用 assertEqual 的那行；如果 deepEqual 也误标了 Helper()，就可能跳过太多层，定位到更外层（比如某个公共测试基类），反而失焦。
示例：
func assertEqual(t *testing.T, got, want interface{}) {
t.Helper() // ← 关键：只在这里标
if !reflect.DeepEqual(got, want) {
t.Errorf("got %+v, want %+v", got, want)
}
}
func TestSomething(t *testing.T) {
assertEqual(t, 1, 2) // ← 失败信息的 "line" 会指向这一行，不是 assertEqual 内部
}
容易被忽略的兼容性与调试陷阱
t.Helper() 自 Go 1.9 加入，老版本不可用；但它不会导致编译失败，只是静默不生效——你仍会看到错误定位在 helper 函数内，却查不出原因。另外，VS Code 或其他 IDE 的测试跳转依赖底层 go test 输出的文件/行信息，如果 helper 标错位置或跨包调用未导出函数，跳转可能失效。
- 检查 Go 版本：
go version≥ 1.9 - 确保 helper 函数是导出的（首字母大写），否则跨包调用时
t.Helper()可能被忽略 - 调试时临时注释掉
t.Helper()，对比失败行号变化，能快速验证是否生效
最麻烦的情况是 helper 函数被多个测试包复用，而其中某个包没升级 Go 版本，或者混用了 testing.TB 接口和具体类型——这时候定位偏差不会报错，只会悄悄失效。
