go标准库testing.t无内置断言函数，需用t.error/fatal系列手动比较；reflect.deepequal有陷阱，推荐cmp.equal；testify等第三方库适用复杂场景但需注意defer失效等问题。
testing.T 没有内置断言函数，别直接调用 assert.Equal
Go 标准库的 testing 包本身不提供任何断言函数（如 assert.Equal、require.NoError），这是有意为之的设计。官方认为显式错误处理更符合 Go 的哲学：用 t.Errorf 或 t.Fatalf 直接报告失败，不隐藏控制流。
常见错误是误以为 Go 原生支持类似 Python 的 self.assertEqual，结果导入了第三方库却没意识到它改变了测试行为（比如 require 系列会提前终止当前测试函数）。
- 标准写法只用
t.Error、t.Errorf（继续执行）、t.Fatal、t.Fatalf（立即返回） - 第三方断言库（如
github.com/stretchr/testify/assert）是独立实现，非语言特性 -
t.Log和t.Helper()可提升失败信息可读性，但不改变断言逻辑
手动比较 + t.Errorf 是最轻量可靠的断言方式
对简单值比较（int、string、bool），直接用 == 配合 t.Errorf 最清晰，无额外依赖，调试时堆栈干净。
func TestAdd(t *testing.T) {
got := Add(2, 3)
want := 5
if got != want {
t.Errorf("Add(2,3) = %v, want %v", got, want)
}
}
- 结构体或切片需逐字段/元素比对，或用
reflect.DeepEqual—— 但注意它对函数、map 迭代顺序、未导出字段行为敏感 - 避免在循环中累积多个
t.Error后才退出；若某次失败就该终止（如初始化错误），改用t.Fatal - 用
t.Helper()标记辅助函数，让错误行号指向调用处而非内部函数
使用 reflect.DeepEqual 要小心这三点
reflect.DeepEqual 常被当作“万能相等判断”，但它在真实项目中容易引发隐晦问题：
立即学习“go语言免费学习笔记（深入）”；
- 对比含
nilmap/slice 与空 map/slice：结果为false（nil == {}不成立） - 对比含函数或
unsafe.Pointer的结构体：panic - 对比 map 时，键值对顺序不影响结果，但若 map 由不同 goroutine 并发写入，迭代顺序不确定可能导致偶发失败
替代方案：cmp.Equal（来自 github.com/google/go-cmp/cmp）更安全，默认忽略未导出字段、支持自定义比较器，且错误信息更详细。
第三方断言库（如 testify）适合复杂场景，但要明确代价
当频繁做嵌套结构比较、错误类型检查、mock 行为验证时，testify/assert 或 testify/require 能减少样板代码：
assert.Equal(t, "hello", resp.Body.String()) require.NoError(t, err) // 后续语句不会执行
-
require类函数用runtime.Goexit实现“提前返回”，导致 defer 不触发——若你依赖 defer 清理资源（如关闭文件、回滚事务），必须手动处理 - 所有 testify 断言都返回
bool，可链式调用但无法用于条件分支（如if assert.NoError(t, err) { ... }是错的） - CI 环境中若测试 panic 且未捕获，可能掩盖真正问题；标准
t.Fatal更易追踪
深层结构比较、HTTP 响应校验、数据库状态断言这些地方，第三方库省事；但基础逻辑验证，手写 if !equal { t.Fatal } 更可控。
