最推荐使用 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语言免费学习笔记（深入）”；
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。
