优先用 t.Logf，因其延迟格式化、性能更优且支持自定义格式；t.Log 仅适用于固定字符串输出，多参数会触发隐式拼接并影响可读性与性能。
测试中用 t.Log 还是 t.Logf？
优先用 t.Logf，除非你只输出一个固定字符串。直接调用 t.Log 传多个参数（比如 t.Log("err:", err)）会触发隐式字符串拼接，既影响可读性，又在测试未失败时白白消耗性能。而 t.Logf 延迟格式化，只有开启 -v 或测试失败时才真正执行 fmt.Sprintf。
- ✅ 推荐：
t.Logf("request ID: %s, status: %d", reqID, statusCode) - ❌ 避免：
t.Log("request ID:", reqID, "status:", statusCode)（参数被转成空格分隔的字符串，且无法控制格式） - ⚠️ 注意：
t.Log和t.Logf的输出默认只在go test -v下可见；失败时自动显示，但不会带时间戳或调用位置
如何让测试日志带上下文和时间戳？
标准 *testing.T 不提供时间戳或调用栈信息，得自己封装。最轻量的方式是写个辅助函数，用 time.Now() + runtime.Caller 补充前缀：
func logf(t *testing.T, format string, args ...interface{}) {
_, file, line, _ := runtime.Caller(1)
now := time.Now().Format("15:04:05.000")
t.Logf("[%s] %s:%d "+format, now, filepath.Base(file), line, args...)
}
调用时：logf(t, "got response: %v", resp)。这样每条日志都带毫秒级时间、文件名和行号，排查并发测试或竞态问题时非常关键。
- 不建议直接改
t.Logf行为——它属于标准库接口，不可覆盖 - 避免在日志里打印大量结构体（如
%+v整个http.Request），会拖慢测试速度，尤其在-race模式下 - 如果项目已用
logrus或zerolog，别在测试里混用——它们默认输出到os.Stderr，不被t.Log捕获，也绕过go test的日志聚合机制
并行测试（t.Parallel()）中日志乱序怎么办？
并行测试的 t.Log 输出本身是线程安全的，但不同 goroutine 的日志会交错打印，看不出哪条属于哪个子测试。解决办法不是禁用并行，而是给每条日志加上测试名前缀：
立即学习“go语言免费学习笔记（深入）”；
func logWithTestName(t *testing.T, format string, args ...interface{}) {
t.Logf("[%s] "+format, t.Name(), args...)
}
再配合 t.Setenv 或自定义字段记录关键上下文（如 mock ID、用户 token），比靠时间戳对齐更可靠。
- ⚠️ 切勿在并行测试中用全局变量或共享
io.Writer记录日志——会引发竞态警告（go test -race会报） -
t.Name()返回的是当前测试的完整名称，包括子测试（如"TestAuth/valid_token"），适合做日志分类 - 如果必须按顺序看日志，临时加
t.Parallel()注释掉，但不要把它当成常态方案——掩盖的是设计问题，不是日志问题
CI 环境下怎么控制测试日志量？
CI 通常不加 -v，所以 t.Log 全部静默。但某些关键路径（如初始化失败、重试循环、mock 调用计数）仍需暴露。这时用 t.Error 或 t.Fatal 附带日志信息，确保失败时可见：
if !ok {
t.Errorf("expected user to be active, got %+v; debug info: %+v", user, debugInfo)
}
或者用 t.Helper() 封装条件日志函数，在失败时才触发：
- 调试阶段：跑
go test -v -run=TestFoo -count=1查详细流 - CI 阶段：靠
t.Error和断言错误消息传递必要信息，而不是依赖t.Log - 长期维护的测试套件，建议把高频调试日志（如“entering retry loop”）升级为结构化断言，比如检查重试次数是否 ≤3，而不是靠日志人工确认
日志不是替代断言的手段。最常被忽略的一点是：很多人花半小时调日志格式，却没给 t.Run 起好名字——后者对 CI 报告的可读性影响远大于时间戳。
