最推荐使用 t.Log 和 t.Logf 输出测试日志，它们缓冲输出、受 -v 控制，轻量且与测试框架集成；避免用 log.Printf 或 fmt.Println，因其绕过测试管理、干扰可读性。

测试中直接用 t.Log 和 t.Logf 输出日志

Go 的 testing.T 提供了 t.Log 和 t.Logf 方法，它们会在测试失败时自动显示，成功时默认不输出（除非加 -v 参数）。这是最轻量、最推荐的测试日志方式。

注意：这些日志不是实时打印到终端，而是缓冲在测试上下文中，只有调用 t.Fail、t.Error 或运行时加 -v 才会展示。

• t.Log("request sent", req.URL) —— 多参数拼接，自动空格分隔
• t.Logf("status code: %d, body len: %d", resp.StatusCode, len(body)) —— 支持格式化，更清晰
• 避免在循环里高频调用 t.Log，可能拖慢测试且干扰可读性

启用详细日志需显式传 -v 参数

默认情况下，go test 不显示 t.Log 内容，哪怕测试通过。想看到所有日志，必须加 -v：

go test -v

也可以只对某个测试启用：

go test -v -run=TestHTTPHandler

常见误区：以为加了 t.Log 就能立刻看到输出，结果没加 -v 什么都没打印，误判为“日志失效”。

• -v 是开关，不是配置项，不能写在代码里或 go.mod 中
• CI 环境中如果看不到日志，第一反应应是检查是否漏了 -v
• go test -v -race 等组合参数也完全兼容

不推荐在测试中用 log.Printf 或 fmt.Println

虽然语法上可以调用全局 log.Printf 或 fmt.Println，但它们绕过了测试框架的生命周期管理：

• 输出不受 -v 控制，总是立即刷屏，干扰测试结果阅读
• 不会和失败信息对齐，无法区分属于哪个测试函数
• 在并行测试（t.Parallel()）中容易混杂不同 goroutine 的日志，难以追踪
• CI 日志归档时，这类输出不会被标记为“测试相关”，检索困难

唯一合理使用场景：调试极早期 setup 阶段（比如 init 函数中），但应尽快删掉。

捕获日志用于断言或验证（如中间件/Handler 日志）

当测试目标本身会打日志（比如 HTTP handler 调用 log.Printf），而你需要断言日志内容是否符合预期，就得替换其输出目标：

func TestHandlerLogs(t *testing.T) {
    var buf strings.Builder
    log.SetOutput(&buf)
    defer log.SetOutput(os.Stderr) // 恢复，避免影响其他测试

    req := httptest.NewRequest("GET", "/health", nil)
    w := httptest.NewRecorder()
    myHandler(w, req)

    if !strings.Contains(buf.String(), "health check OK") {
        t.Error("expected log containing 'health check OK'")
    }
}

关键点：

• 用 strings.Builder 或 bytes.Buffer 替换 log.SetOutput，比重定向文件更轻量
• 务必 defer 恢复原始输出，否则后续测试日志可能丢失
• 如果被测代码用的是第三方 logger（如 zap、zerolog），需按其文档替换 core 或 Writer，不是改 log 包

这种捕获方式本质是“测试依赖的副作用”，只在验证日志行为本身时才需要；日常调试请优先用 t.Log + -v。