Go测试中不手写if断言因易漏错误信息、格式不统一、定位难，且缺乏t.Helper()和并发支持；标准库刻意不提供断言以鼓励显式检查，社区多用testify/assert（新路径github.com/stretchr/testify/assert），它类型安全、自动t.Helper()、差异友好、错误链展开准确；简单场景用原生t.Errorf需带预期/实际值及上下文；自定义断言必调t.Helper()并注意延迟求值。
Go 测试里为什么不用 if !cond { t.Fatal() } 手写断言
因为容易漏掉错误信息、不统一格式、难以定位失败位置，而且 t.Helper() 和测试上下文（如并行测试）支持差。标准库没提供断言函数是刻意设计——鼓励显式检查 + 清晰失败消息，但手写重复逻辑太累，所以社区普遍用第三方库补足。
推荐用 testify/assert 而不是 github.com/stretchr/testify 的旧路径
新模块路径是 github.com/stretchr/testify/assert，旧 import 会触发 Go 模块解析错误或版本混乱。它提供类型安全、可读性强的断言，且所有函数默认调用 t.Helper()，失败时自动指向调用行而非库内部。
-
assert.Equal(t, expected, actual)比reflect.DeepEqual更友好：对 slice/map 会输出差异片段 -
assert.NoError(t, err)自动展开错误链（Go 1.13+），比assert.Nil(t, err)更准 -
assert.Contains(t, "hello world", "world")支持字符串、slice、map 键，不强制类型一致 - 避免用
require包除非真要中断当前测试函数——它用t.Fatal，会跳过后续断言，掩盖多个问题
原生 testing.T 足够应付简单场景，关键在消息写清楚
不需要引入依赖时，直接用 t.Errorf 或 t.Fatalf 更轻量，也更可控。重点不是“有没有断言函数”，而是失败时能否一眼看出哪错了。
- 不要写
t.Errorf("failed")—— 必须包含预期值、实际值、上下文，例如：t.Errorf("ParseTime() = %v, want %v (input: %q)", got, want, input) - 结构体比较慎用
==，应优先用reflect.DeepEqual并手动打印 diff（可用spew.Sdump或fmt.Sprintf("%#v", x)） - 并发测试中，
t.Log输出可能交错，但t.Error会聚合到测试结果里，更适合做断言依据
自定义断言函数要注意 t.Helper() 和参数求值时机
自己封装断言时，必须在函数开头调用 t.Helper()，否则失败堆栈指向的是你的函数而非测试用例。另外，避免在断言函数签名里直接接收表达式结果（比如 assertEqual(t, fn(), 42)），因为 fn() 会在断言前执行，无法延迟求值。
- 正确方式：用函数类型参数实现延迟求值，例如
assertResult(t, func() int { return fn() }, 42) - 或接受接口{}但内部用反射取值，不过会损失类型信息和性能
- 别在断言函数里 recover panic——测试本身已运行在独立 goroutine，panic 会被
testing捕获并转为失败，手动 recover 反而干扰行为
真正卡住人的往往不是选哪个库，而是错误信息里缺输入值、没标注字段名、或者用了 require 后发现本该失败的 case 被静默跳过了。
