不能写全局assert函数，因其在非测试文件中调用会导致panic丢失上下文、堆栈定位错误、无法集成go test -v、易误入生产环境崩服务，且违背Go测试哲学；正确做法仅限_test.go中封装断言函数，且必须接收*testing.T并首行调用t.Helper()。
Go 没有内置 assert，也不该在业务代码里用 panic 模拟断言；真要用，只应在 _test.go 文件中、配合 *testing.T 封装，且必须加 t.Helper()。
为什么不能写全局 assert 函数
常见错误是定义一个包级 func assert(b bool)，然后在非测试文件里调用。它看似简洁，实则埋雷：
- 编译期不报错，但运行时 panic 会丢失上下文，堆栈指向
assert内部而非调用处 - 无法和
go test -v集成，失败时不显示测试名、行号、预期/实际值 - 生产环境若误留此类调用，panic 可能直接崩掉服务（尤其没 recover 时）
- 违反 Go 测试哲学：断言是测试行为，不是语言特性，不该侵入业务逻辑
测试中怎么写才对：t.Helper() 是硬性门槛
自定义断言函数可以写，但仅限于重复逻辑多的场景（比如校验 HTTP 响应头、JSON 字段嵌套存在性），且必须满足两个条件：
- 第一个参数必须是
*testing.T - 函数第一行必须调用
t.Helper()
否则 go test -v 报错时，你会看到失败定位在封装函数内部，而不是你写测试的那一行。例如：
立即学习“go语言免费学习笔记（深入）”；
func AssertJSONHasField(t *testing.T, body []byte, field string) {
t.Helper() // ← 必须有，否则报错行号错乱
var data map[string]interface{}
json.Unmarshal(body, &data)
if _, ok := data[field]; !ok {
t.Fatalf("expected field %q not found in JSON", field)
}
}
什么时候根本没必要封装
简单值比较（int、string、bool）直接写 if 更清晰、更安全：
-
if got != want { t.Errorf("got %v, want %v", got, want) }—— 行为明确，无隐藏控制流 - 封装成
AssertEqual(t, got, want)反而增加函数调用开销，还掩盖了具体比较逻辑 - IDE 能直接跳转到出错行；而封装后需多一层跳转，调试成本上升
- Go 标准库测试用例（如
net/http、encoding/json）几乎全用裸if + t.Error形式
类型断言别和测试断言混为一谈
名字都叫“断言”，但 x.(T) 和测试里的 t.Fatal 完全是两回事：
-
x.(T)是运行时类型检查，用于从接口提取具体类型，失败会 panic（不带ok）或返回 false（带ok） - 测试断言是人为判断逻辑是否符合预期，本质是条件分支 + 错误报告
- 别试图用
x.(T)替代t.Errorf—— 它解决的是类型问题，不是业务逻辑正确性问题 - JSON 解析后得到
[]interface{}，想转成[]map[string]interface{}？不能直接断言，得遍历每个元素再逐个断言 —— 这正是容易忽略的复杂点
