go 无内置 assert，应避免自定义全局 assert 函数；单元测试中应使用 *testing.t 的 helper()、errorf() 等方法进行断言。
Go 里没有 assert 函数，但可以用 testing.T 的方法模拟
Go 官方不提供类似 Python 的 assert 语句或函数，也不是语言特性。强行自己写一个全局 assert 函数在非测试包里既难维护又易掩盖错误。真正该用的地方，是单元测试——此时直接用 *testing.T 提供的 Helper()、Errorf()、
就够了。</p> <p>常见错误：在业务逻辑里 import <code>"testing"并试图调用
t.Fatal() —— 这会导致编译失败，因为 *testing.T 只在 go test 启动的上下文中有效。
- 只在
_test.go文件中使用断言式逻辑 - 每个断言后加
t.Helper()，让报错定位到调用行而非断言函数内部 - 避免封装成
AssertEqual(t, a, b)这类“看起来简洁”实则削弱可读性的函数；直接写if a != b { t.Fatalf("...") }更清晰
自定义断言函数必须接收 *testing.T 并标记 Helper()
如果项目大、断言逻辑重复多（比如要校验结构体字段、HTTP 响应头、JSON 字段存在性），可以封装，但必须满足两个硬性条件：参数含 *testing.T，且第一行调用 t.Helper()。否则 go test -v 报错时会指向封装函数内部，而不是你写断言的那一行。
例如检查 map 是否包含 key：
立即学习“go语言免费学习笔记（深入）”；
func AssertMapHasKey(t *testing.T, m map[string]interface{}, key string) {
t.Helper()
if _, ok := m[key]; !ok {
t.Fatalf("map missing key %q", key)
}
}
- 不加
t.Helper()→ 错误堆栈显示在AssertMapHasKey第 3 行，而非测试文件里调用它的那行 - 返回 bool + 手动
t.Error()不如直接t.Fatal()或t.Errorf()明确意图 - 不要为简单比较（如 int 相等）封装——它比原生 if 多一次函数调用，还藏了控制流
生产环境别用 panic 模拟断言，更别用 recover 捕获
有人会写 func assert(b bool) { if !b { panic("assert failed") } } 并在 main 包里调用。这是危险模式：panic 不是错误处理机制，它会中断 goroutine，且无法被常规 error 流程捕获。线上服务一旦触发，可能丢请求、卡协程、甚至导致整个进程退出。
- 生产代码中，所有输入校验应返回
error，由上层决定重试/降级/告警 - 用
panic仅限于“程序不可能走到这里”的开发期假设（如 switch 覆盖所有 enum 值后 default 分支），且不应依赖 recover 拦截 - 如果真需要运行时快速失败（如配置加载阶段），用
log.Fatal()显式退出，比 panic 更可控、日志更清晰
第三方断言库（如 testify/assert）的取舍要点
testify/assert 提供了 Equal()、Contains() 等函数，写起来像其他语言的 assert，但要注意它底层仍是调用 *testing.T 方法，并做了 Helper() 处理。是否引入，取决于团队共识和项目规模。
- 优势：链式调用、自动 diff 输出、支持自定义消息（
assert.Equal(t, a, b, "user ID mismatch")） - 代价：多一个依赖；某些方法（如
assert.JSONEq()）内部用encoding/json序列化对比，对大 payload 有性能开销 - 注意：
assert的函数默认失败不终止测试（返回 false），要用require包才等价于t.Fatal()；混用容易漏掉关键失败
小项目或内部工具脚本，原生 *testing.T 足够；中大型服务且测试密度高，testify 可减少样板代码，但得统一用 require 避免静默失败。
