应封装 assertNoError 函数替代重复的 assert.NoError(t, err)，需加 t.Helper() 确保正确行号，用 t.Fatalf 避免遗漏 return，支持可变 msg 参数，兼顾调试性与轻量性。
Go 测试中重复写 assert.NoError(t, err) 很累？直接封装函数就行
Go 标准测试不带断言库，很多人靠 if err != nil 手动 panic 或调用 t.Fatal，但写多了容易漏 t.Helper()、错失堆栈定位，或误把非关键错误当致命问题。自定义断言函数不是为了“更像其他语言”，而是让错误检查可复用、可调试、行为一致。
- 必须加
t.Helper()，否则报错行号指向封装函数内部，不是测试用例里那行 - 别用
t.Fatalf一棍子打死——有些测试需要继续验证后续逻辑（比如检查 error 是否为特定类型后再看返回值） - 参数顺序建议统一为
(t *testing.T, err error, msg ...string)，和标准库require.NoError保持一致，降低团队认知成本
为什么不用第三方 assert 库（比如 testify）？
不是不能用，而是很多项目卡在“只差一个轻量断言”就引入新依赖。testify 的 assert.NoError 确实好用，但它会吞掉原始 error 的完整类型信息（比如 *os.PathError），导致你没法做 errors.Is 或 errors.As 判断；而自己写的函数可以透传 error，该断言类型时就断言类型，该打印详情时就打印详情。
- 第三方库的失败消息格式固定，有时掩盖关键上下文（比如没显示你传进来的
msg） - 交叉编译或 CI 环境里多一个依赖，就多一个版本兼容风险（尤其是
testifyv1/v2 的require行为差异） - 简单场景下，5 行函数比 import + 学文档更快上线
assertNoError 函数怎么写才不踩坑？
核心就三点：帮调用者省事、不干扰调试、兼容常见错误处理模式。下面这个版本经过多个项目验证：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func assertNoError(t *testing.T, err error, msg ...string) {
t.Helper()
if err == nil {
return
}
message := strings.Join(msg, " ")
if message != "" {
message = " " + message
}
t.Fatalf("expected no error, got %v%s", err, message)
}
- 用
t.Fatalf而不是t.Error+return，避免忘记 return 导致后续代码误执行 - 支持可变参数
msg，方便补充上下文（比如assertNoError(t, err, "when creating temp dir")） - 不强制要求 error 实现
Error() string——万一有人传nil指针进去，%v也能安全输出<nil></nil>
更进一步：区分 fatal 和 non-fatal 场景
有些测试里，你只想记录错误但继续跑（比如批量校验多个文件），这时 t.Fatal 就太重了。可以补一个 checkNoError：
立即学习“go语言免费学习笔记（深入）”；
func checkNoError(t *testing.T, err error, msg ...string) {
t.Helper()
if err != nil {
message := strings.Join(msg, " ")
t.Logf("unexpected error: %v%s", err, message)
}
}
-
t.Logf不中断执行，适合“收集所有失败项”的场景 - 注意它不会自动 fail 测试——如果要让测试最终失败，得自己加
t.Fail()或配合testing.T.Cleanup统计 - 别把它和
assertNoError混用：一个负责“立刻止损”，一个负责“留痕观察”，语义必须清晰
真正麻烦的从来不是写几行断言函数，而是所有人对 “这个 error 是不是应该中断测试” 理解不一致。所以函数名、文档注释、甚至 Git 提交信息里，都得明确写出它的终止性行为——否则半年后你自己 review 代码时，也会犹豫那一行 assertNoError 到底该不该删。
