应优先用 require 而非 assert 实现失败即止，因 assert 失败仅记录日志不终止执行；require.noerror 等用于前置条件校验，assert 适用于无依赖的并列状态检查，混合使用时需避免 require 后跟 panic 风险代码。
Testify 的 assert 和 require 到底该用哪个
多数人一开始就把 assert 当成“更好看的 if”，结果测试跑一半挂了却没报错——因为 assert 失败只打日志、不终止执行。真正想让测试立刻停在失败点，得用 require。
典型场景：需要前置条件成立才能继续（比如初始化 DB 连接、读取配置文件）。这时用 require.NoError(t, err)，失败直接退出当前测试函数；而 assert.NoError(t, err) 即使出错也会继续跑后续断言，可能触发 panic 或误判。
-
assert适合“检查多个独立状态”，比如验证返回值字段是否符合预期，各断言之间无依赖 -
require适合“链式依赖步骤”，比如require.JSONEq比对结构后，再用assert检查其中某个字段值 - 混合使用是常态，但别在
require后写可能 panic 的代码（如解引用 nil），否则错误堆栈会掩盖真实断言失败点
为什么 assert.Equal 有时不报错，但值明明不一样
Go 的接口比较、切片比较、map 比较都容易踩坑：assert.Equal 用的是 reflect.DeepEqual，它对 nil slice 和空 slice（[]int{}）视为相等，对含 unexported 字段的 struct 可能静默失败。
常见现象：测试里 assert.Equal(t, want, got) 没报错，但业务逻辑出问题；或者反过来，两个看起来一样的 map 被判为不等。
立即学习“go语言免费学习笔记（深入）”；
- 切片/数组：优先用
assert.ElementsMatch（忽略顺序）或assert.Exactly（严格类型+值一致） - struct：确保所有字段可导出；若含 time.Time，用
assert.WithinDuration替代Equal - JSON 字符串比对：别用
Equal，改用assert.JSONEq，它自动忽略空格、键序、float 精度差异
在 table-driven 测试里怎么组织 assert 调用才不丢上下文
table-driven 测试一旦失败，只看到 “assertion failed”，根本不知道是第几个 case、输入是什么。直接在循环里写 assert.Equal(t, tc.want, got) 会让调试成本飙升。
关键不是少写断言，而是让每个失败带上可定位信息。
- 给每个 case 加唯一
name字段，并在t.Run中使用：t.Run(tc.name, func(t *testing.T) { ... }) - 所有
assert调用前加t.Helper()，这样错误位置指向测试数据行，而非 testify 内部 - 复杂比对时，手动打印输入输出：
t.Logf("input: %+v, want: %+v, got: %+v", tc.input, tc.want, got)
引入 Testify 后测试变慢？注意 assert 的副作用
assert 系列函数内部会调用 runtime.Caller 获取文件行号，再拼接失败消息。这在单次调用中不明显，但在高频循环（如 10k 次表驱动 case）里会显著拖慢测试速度。
不是说不能用，而是得知道代价在哪。
- 性能敏感路径（如 benchmark 或大数据量验证），先用原生
if !reflect.DeepEqual(got, want) { t.Fatalf(...) } - 避免在 for 循环内反复调用
assert.JSONEq解析同一段 JSON 字符串，提前解析好再比对 - CI 环境下如果发现 test 执行时间突增，可以临时替换为
require+t.Log组合，减少反射开销
Testify 的价值不在“有没有”，而在“什么时候用、用多少”。断言本身不解决逻辑问题，只是把问题暴露得更早、更准——前提是别让它藏在嵌套调用或模糊消息里。
