Go 语言需用 testify/assert 实现断言，assert.Equal 默认不输出详细 diff，应对复杂类型用 EqualValues 或 ObjectsAreEqual；require 失败即终止测试，assert 则继续执行；HTTP 响应宜解码后结构化比对，自定义类型应实现 String() 提升错误可读性。
Go 语言原生没有 assert 机制，testify 的 assert 包是目前最主流的断言补充方案，但它不是“开箱即用”的魔法——用错方式会导致测试失败难定位、误报或漏报。
为什么 assert.Equal 失败时不打印详细 diff？
默认情况下 assert.Equal 只输出简略错误信息，比如 expected: 42, got: 43，对结构体或长字符串完全不友好。根本原因是没启用深度比较的可读格式化输出。
- 确保导入的是
github.com/stretchr/testify/assert（不是require或mock） - 对复杂类型（如
map、嵌套struct），优先用assert.EqualValues——它会递归比较值而非指针/地址 - 若仍需完整 diff，改用
assert.ObjectsAreEqual+ 自定义格式化，或直接切换到require包（见下节）
require 和 assert 的关键区别在哪？
require 不是更“强”的断言，而是失败时直接调用 t.Fatal 终止当前测试函数；assert 只记录错误，允许后续断言继续执行。选错会导致逻辑误判或掩盖真实问题。
- 验证前置条件（如
json.Unmarshal成功）必须用require.NoError：否则后续代码可能 panic 或读取 nil - 批量校验多个字段（如 API 响应字段）适合用
assert：一次看到所有不匹配项 -
require的函数签名和assert完全一致，仅行为不同，可无痛切换
测试 HTTP handler 时如何用 assert 检查响应体？
直接对 *httptest.ResponseRecorder.Body 调用 assert.Equal 很容易因换行、空格、JSON 序列化顺序导致误判。核心是先标准化再比对。
立即学习“go语言免费学习笔记（深入）”；
func TestMyHandler(t *testing.T) {
req := httptest.NewRequest("GET", "/api/user", nil)
rr := httptest.NewRecorder()
handler := http.HandlerFunc(MyHandler)
handler.ServeHTTP(rr, req)
// 正确：解码 JSON 后比较结构体，绕过格式差异
var resp map[string]interface{}
assert.NoError(t, json.Unmarshal(rr.Body.Bytes(), &resp))
assert.Equal(t, "success", resp["status"])
assert.Equal(t, float64(200), resp["code"]) // 注意 JSON number 默认是 float64
// 错误示例（避免）：
// assert.Equal(t, `{"status":"success","code":200}`, rr.Body.String())
}
自定义类型断言失败时提示信息太模糊怎么办？
当结构体字段多、嵌套深时，assert.Equal 默认只显示 “expected …, got …”，看不出具体哪个字段不一致。根本解法是让类型实现 String() 方法，或用 assert.Exactly 强制类型+值双重匹配。
- 为测试专用结构体添加
String()：返回精简可读字段，便于快速定位 - 对时间、浮点数等易精度误差类型，用
assert.InDelta或assert.WithinDuration - 避免在断言中拼接长字符串作
msg参数——它只会追加在默认错误后，不替代原始 diff
真正麻烦的不是不会写 assert.Equal，而是没意识到它的输出本质是 fmt.Sprintf 格式化结果——一旦值本身不可读（比如未实现 Stringer 的 struct），断言失败就只剩内存地址和空括号。调试时花三分钟加个 fmt.Printf("%+v", v)，往往比翻文档快得多。
