testify解决go原生测试三大痛点：错误信息无diff、结构体比较繁琐、json响应敏感空格；assert.equal支持深比较与nil slice等价判断，assert.jsoneq语义比对json，assert.erroras提取自定义错误类型，require.noerror用于前置校验熔断执行。
Testify 不是用来“增强表达力”或“追求美学”的装饰品，它解决的是 Go 原生测试里最痛的三个问题：错误信息看不见差异、结构体比较写起来像搬砖、JSON 响应一空格就挂。
assert.Equal 为什么比 if got != want { t.Errorf } 更可靠
原生写法在结构体、map、切片上容易误判，比如 nil slice 和 []int{} 被判为不等，而业务上它们常视为等价；assert.Equal 内部做了语义对齐，深比较时自动处理这类边界。
- 失败时直接输出带缩进的 diff，字段级差异一目了然，不用手动拼日志
- 支持
time.Time、struct、嵌套map[string]interface{}，无需额外reflect.DeepEqual包裹 - 所有
assert.Xxx函数返回bool，但默认不中断执行——这点常被忽略，导致后续断言在零值上运行出 panic
require.NoError 必须用在解析/调用之后，不是可选项
HTTP handler 或数据库查询后只用 assert.NoError(t, err) 是高危操作。一旦 err 非 nil，后续访问 resp.Data 或 user.ID 就是零值读取，要么 panic（堆栈指向字段访问行），要么断言通过但逻辑错漏。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 前置校验必须用
require.NoError(t, err)，它调用t.Fatal熔断执行，错误定位精准到源头 -
require.NoError不返回bool，不能写成if require.NoError(...) { }，会编译失败 - 典型位置：json.Unmarshal 后、Repo.FindOne 返回后、config.Load() 后
JSON 响应别比字符串，用 assert.JSONEq 而不是 assert.Equal
API 返回体含时间戳、UUID、浮点数或字段顺序不固定时，assert.Equal(t, `{"id":1,"name":"foo"}`, string(body)) 极其脆弱——多一个空格、小数位差一位、键顺序一换就失败。
-
assert.JSONEq(t, wantJSON, string(body))先两边json.Unmarshal，再按语义比较，忽略格式与键序 - 非法 JSON 会导致 panic，务必在
assert.JSONEq前加校验，比如assert.True(t, json.Valid(body)) - 动态字段（如
"created_at": "2026-07-14T18:44:00Z"）需先用strings.ReplaceAll或正则抹除，再喂给assert.JSONEq
自定义 error 类型要用 assert.ErrorAs，不是 assert.Equal
微服务里常见封装错误：fmt.Errorf("failed to fetch user: %w", ErrUserNotFound)。用 assert.Equal(t, ErrUserNotFound, err) 永远失败——它只比 err.Error() 字符串，不递归 errors.Unwrap()，也不识别底层类型。
- 正确做法是
assert.ErrorAs(t, err, &target)，其中target必须是非 nil 指针，例如new(*UserNotFoundError) -
assert.ErrorIs适合检查是否包装了某个已知错误，比如assert.ErrorIs(t, err, sql.ErrNoRows) - 表驱动测试中每个 case 的断言必须带上下文，否则失败时无法快速定位是哪个输入路径出问题
真正难的不是学会 assert 函数名，而是判断哪一步该用 require 熔断、哪一步该用 assert 继续、哪一步该预处理再喂给 JSONEq——这些决策点藏在调用链的依赖关系里，不在文档里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
