17370845950

testing.T.Log 和 testing.T.Logf 默认仅在测试失败时输出，成功时需加 -v 参数才可见；应优先使用 t.Log 而非 fmt.Println，以确保日志归属清晰、受测试框架管理。

testing.T.Log 和 testing.T.Logf 为什么看不到输出

默认情况下，testing.T.Log 和 testing.T.Logf 的内容只在测试失败时才打印到终端。这是 Go 测试框架的默认行为，不是 bug，而是设计选择——避免成功测试产生大量干扰日志。

实操建议：

• 运行测试时加 -v 参数强制显示所有日志：

  go test -v

• 若只对某个测试启用详细日志，可在命令中指定测试名：

  go test -v -run=TestMyFunc

• 注意：即使加了 -v，t.Log 仍只在当前测试函数内输出；它不会跨测试传播，也不影响其他 t.Parallel() 子测试的日志可见性

如何让 t.Log 在失败时自动带上行号和调用栈

Go 标准库不提供自动行号标记，但可通过包装函数或自定义 helper 实现类似效果。关键是利用 runtime.Caller 获取调用位置。

实操建议：

• 不要直接在测试里反复写 runtime.Caller(1)，封装成辅助函数更可靠
• 避免在循环中高频调用 runtime.Caller，有轻微性能开销（微秒级，但上万次会累积）
• 下面是一个轻量封装示例（放在测试文件内即可）：

func logf(t *testing.T, format string, args ...interface{}) {
  _, file, line, _ := runtime.Caller(1)
  t.Logf("[%s:%d] "+format, append([]interface{}{filepath.Base(file), line}, args...)...)
}

使用时：logf(t, "request ID: %s", id)，输出形如 [mytest_test.go:42] request ID: abc123

测试中使用 t.Log 还是 fmt.Println

必须用 t.Log，不能用 fmt.Println。后者输出不受测试生命周期管理，会导致三类问题：

• 并行测试（t.Parallel()）中，多个 goroutine 的 fmt.Println 输出会混在一起，无法归属到具体测试
• 当测试被 go test -run=... 筛选时，fmt.Println 仍会输出，而 t.L

  

  og 会被框架静默丢弃（符合预期）
• CI 环境中，某些测试报告工具（如 gotestsum）只解析 t.Log 行为，忽略 fmt 输出

例外场景：调试极早期初始化（比如 init() 函数、全局变量赋值），此时 *testing.T 尚未构造，只能用 fmt 或 log.Printf，但这类日志不属于“测试日志”，应尽快移除

如何在子测试（t.Run）中控制日志粒度

子测试共享父测试的 *testing.T 实例，但 t.Log 输出天然绑定到当前子测试作用域。关键点在于：子测试失败时，只会打印该子测试内的 t.Log，不会带出父测试或其他子测试的日志。

实操建议：

• 在 t.Run 内部调用 t.Log 是安全且推荐的，无需额外处理
• 如果想区分层级，可手动加前缀：t.Logf("step1: got response %v", resp)
• 避免在子测试里调用 t.Fatal 后还写 t.Log —— 它不会执行，Go 会直接终止该子测试
• 注意：子测试中调用 t.Setenv 或 t.TempDir 不会影响日志行为，但可能改变实际输出内容（比如环境变量影响日志格式）

日志本身没有“嵌套”概念，所谓“子测试日志”只是输出文本带上了子测试名称前缀，由测试框架自动添加。