assert断言失败仅记录错误并继续执行，require失败则立即终止测试函数；前者适用于多条件独立验证，后者用于前置依赖校验。
assert 和 require 的核心行为差异
断言失败时，assert 只记录错误但继续执行后续测试；require 遇到失败直接终止当前测试函数（不会跑完剩下的断言）。这不是风格偏好，而是控制流设计：前者适合“检查多个独立条件”，后者用于“前置依赖必须成立”。
常见错误现象：require.Equal(t, got, want) 失败后，后续的 assert.Contains(t, output, "error") 根本不执行——有人误以为是断言没生效，其实是被 require 提前截断了。
- 用
require做初始化校验：比如解析 JSON、打开文件、获取配置值 - 用
assert做多点验证：比如 HTTP 响应状态码、Header、Body 三者都要检查 - 混合使用没问题，但要注意顺序：前置依赖用
require，平行验证用assert
Testify assert 包里哪些函数带 panic 风险
所有 assert.* 函数本身不 panic，但它们返回 bool。如果你手动调用 panic() 或用 if !assert.XXX(...) { panic(...) }，就等于自己引入了非标准中断逻辑——这会绕过 testing.T 的错误收集机制，导致测试报告漏掉堆栈和上下文。
正确做法是信任 assert 自身的错误输出机制。它内部调用 t.Helper() 和 t.Errorf()，确保错误归属清晰。
- 避免手写
if !assert.Equal(...) { t.Fatal(...) }—— 这既冗余又破坏assert的批量报告能力 -
assert.NoError(t, err)比require.NoError(t, err)更适合用于“这个 err 不该存在，但我想继续看后续逻辑是否也出错” - 没有
assert.Panic这种函数；要测 panic 请用assert.Panics或require.Panics，它们封装了 recover 逻辑
require.NoError 在 defer 清理场景下的陷阱
在 defer 里用 require.NoError 是危险的。因为 require 失败会调用 t.FailNow()，而 FailNow 会跳过当前函数剩余代码——包括还没执行的其他 defer 语句。这意味着资源可能泄漏，且错误信息只显示最后一个 require 的内容，掩盖了真正的问题源头。
典型场景：打开临时文件 → 测试逻辑 → defer require.NoError(t, f.Close())。如果 f.Close() 报错，测试立即终止，前面的 defer os.Remove(...) 就不会运行。
- 清理逻辑一律用
assert.NoError，哪怕它不中断流程——资源清理失败不该让测试“假阴性”中断 - 真要强制中断（比如关键 cleanup 必须成功），改用普通
if err := f.Close(); err != nil { t.Fatalf("close failed: %v", err) }，明确表达意图 - 测试函数末尾补一句
assert.Empty(t, t.Failed())可辅助判断是否遗漏 cleanup 错误
自定义断言函数如何与 require/assert 兼容
自己封装断言函数时，若想同时支持 assert 和 require 行为，不能直接传入 *testing.T 并调用 t.Fatal。必须通过 assert.AnError 或 require.AnError 的方式，把底层判断逻辑分离出来，再由调用方决定用哪个入口。
例如写一个检查 map 是否包含某 key 的函数：
func MapHasKey(t *testing.T, m map[string]interface{}, key string) bool {
_, ok := m[key]
if !ok {
assert.Fail(t, "map does not contain key", "key=%s", key)
return false
}
return true
}
这样调用方可以自由选择：assert.True(t, MapHasKey(t, m, "id")) 或 require.True(t, MapHasKey(t, m, "id"))。
- 不要在封装函数里调用
t.Fatal或t.FailNow—— 这会锁死使用者的选择 - 函数返回
bool是最佳实践，和assert/require原生函数保持一致 - 如果封装逻辑复杂（比如要多次调用
assert），记得在函数开头加t.Helper()，让错误行号指向调用处而非封装内部
