Go测试中应优先使用testify/assert而非原生功能；比较自定义错误须用ErrorAs而非Equal；NoError与require.NoError差异在于失败后是否终止测试；结构体/切片比较依类型严格性选Equal或EqualValues；表格测试需为断言添加case上下文前缀。
testify/assert 不是 Go 原生功能，但它是目前最实用、错误信息最友好的断言方案；关键不是“能不能用”，而是“怎么用才不掩盖问题”。
为什么不能直接用 assert.Equal 比较自定义错误类型
Go 的 errors.As 和 assert.ErrorAs 处理的是「错误类型断言」，而 assert.Equal 只做值比较——它不会递归 Unwrap()，也不识别包装错误链。比如：
-
fmt.Errorf("wrap: %w", &os.PathError{})和*os.PathError用Equal比较永远失败 -
Equal打印的是err.Error()，丢失堆栈、字段、底层类型信息 - 想确认错误是否为某具体类型，必须用
assert.ErrorAs(t, err, &target)，且target必须是非 nil 指针（如new(*os.PathError)）
assert.NoError 和 require.NoError 的行为差异在哪
两者都调用 errors.Is(err, nil)，但失败后处理逻辑完全不同：
-
assert.NoError(t, err)：失败时调用t.Logf打印错误，测试继续执行 -
require.NoError(t, err)：失败时调用t.Fatal，当前测试函数立刻终止 - 若后续代码依赖
err == nil（比如要访问result.Data），不用require就可能 panic 或产生误判 -
require不返回 bool，所以不能写成if require.NoError(...) { ... }—— 会编译报错
结构体/切片比较该选 Equal 还是 EqualValues
区别在于「类型严格性」：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
assert.Equal(t, []int{1,2}, []int64{1,2})→ 失败，因为[]int≠[]int64 -
assert.EqualValues(t, []int{1,2}, []int64{1,2})→ 成功，只比值，忽略底层类型 - 结构体字段顺序、导出性、嵌套类型全一致时，
Equal更安全；仅需语义等价时，EqualValues更宽容 - 对含未导出字段的结构体，
Equal可能因反射权限失败，EqualValues同样受限，此时建议实现String()或手动比关键字段
表格驱动测试中容易漏掉的错误前缀
每个 t.Run 子测试失败时，错误日志默认只显示文件行号，不带 case 上下文。不加前缀会导致：
- 多个 case 共享同一行
assert.Equal，失败时分不清是哪个输入出错 - CI 日志里无法快速定位问题 case，尤其当
tc.name是空字符串或重复时 - 正确做法是在所有
t.Errorf或 assert 调用中显式传入描述性消息，例如：assert.Equal(t, tc.want, got, "case %q", tc.name) - 更稳妥的方式是统一用
tc.name作为t.Run名称，并在 assert 失败消息里复用它，避免手误错配
真正难的不是记住函数名，而是每次写 assert 时，都得想清楚：这个断言失败后，我能不能一眼看出「哪里不对」「为什么不对」「跟哪个输入有关」——其余都是细节。
