Go标准库无assert，应使用testing.T的Errorf/Fatalf；避免封装断言导致行号错乱；慎用testify/assert；结构体比较优先用EqualValues或自定义Equal方法；仅领域专用高频检查才考虑自定义断言。
Go里没有assert函数，别硬套Python那一套
Go语言标准库不提供assert，强行写个全局assert函数容易破坏测试的可读性和失败定位。官方testing.T的Errorf、Fatalf才是正解——它们自带文件名和行号，失败时一眼看到哪一行挂了。
常见错误是封装一层“看起来更简洁”的AssertEqual，结果报错信息变成封装函数内部的行号，调试时得点进工具函数再折回来。
- 用
t.Errorf("expected %v, got %v", want, got)代替assert.Equal(t, want, got) - 需要提前终止测试时，用
t.Fatalf，不是panic（会丢失testing上下文） - 如果真要复用断言逻辑，把检查逻辑拆成返回
bool或error的纯函数，测试里显式调用并处理
用testify/assert前先想清楚代价
testify/assert确实写起来顺手，assert.Equal(t, a, b)比原生少打几个字。但它会让测试依赖第三方、增加编译体积、且默认不打印完整结构体差异（需开assert.ExtraFailureMessage）。
更隐蔽的问题是：它把“失败”和“报告”耦合在一条语句里，没法在检查后做额外动作（比如记录指标、触发清理）。而原生t.Error是明确的两步：判断 + 报告。
立即学习“go语言免费学习笔记（深入）”；
- 小项目或CI环境受限时，优先用标准库；团队已统一用
testify且维护良好，可以接受 - 若要用，务必加
import _ "github.com/stretchr/testify/assert"避免误删导入（Go 1.21+ 可用//go:build test隔离） - 结构体比较用
assert.EqualValues而非Equal，否则int和int64会误判失败
if !reflect.DeepEqual(a, b)不是万能解，小心性能和可读性
有人一遇到复杂结构就上reflect.DeepEqual，但它慢、不透明、报错只说“not equal”，没指出具体哪个字段不同。而且对含func、unsafe.Pointer或循环引用的值直接panic。
真正该用它的场景其实很窄：临时验证两个动态生成的map/slice是否内容一致，且你控制得了数据结构。
- 测试中比较自定义类型，优先实现
Equal(other T) bool方法，比反射快10倍以上 - 必须用
reflect.DeepEqual时，先if a == nil || b == nil短路，避免空指针panic - 日志里打印差异？改用
spew.Dump(a, b)（github.com/davecgh/go-spew/spew），但别进生产代码
自定义断言工具的唯一合理场景：领域专用检查
只有当你反复写同一类检查逻辑，且标准库+testify都覆盖不到时，才值得封装。比如HTTP handler测试里频繁校验响应头+状态码+JSON body结构，这时写个assertResponse(t, resp, status, headers, jsonBody)才有意义。
关键不是“有没有assert”，而是“这个封装是否让失败原因更清晰、复用是否真省事”。多数情况下，多敲几行t.Error比引入一个新抽象更可靠。
- 函数名必须带动词和领域词，如
assertValidUUID，别叫myAssert - 参数顺序固定：
(t *testing.T, actual, expected ...)，和标准库保持一致 - 内部仍用
t.Helper()标记，否则行号指向工具函数而非调用处
最常被忽略的是：自定义断言一旦写出，就等于承诺长期维护。下次重构结构体字段时，你得同步改断言逻辑——而原生t.Errorf散落在各处，反而改得更轻量。
