Golang测试日志输出的最佳实践

优先用 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 报告的可读性影响远大于时间戳。