Go t.Logf 在并行测试中怎样组织诊断输出

并行子测试里的 t.Logf，关键不是“把文字打印出来”，而是让每条诊断信息带着正确的测试上下文。做法是：在 t.Run 创建的子测试内部调用 t.Parallel()，再用 t.Logf 写入用例名、输入和关键分支；普通成功运行保持安静，失败或加上 -v 时再查看日志。不要在测试函数返回后通过 goroutine 继续写日志，也不要把共享可变变量直接交给并行用例。

先把 t.Logf 当作测试日志，而不是 fmt.Printf

t.Logf(format, args...) 会按格式化规则记录一条测试日志，并自动补换行。与 fmt.Printf 不同，它属于当前测试上下文：正常运行时可能不显示，测试失败时会随失败用例输出；加上 go test -v 后，成功用例的日志也会出现。

因此日志消息最好先写“谁在记录”，再写“记录了什么”。只写 got=%v，在多个并行用例同时失败时很快就会失去上下文。

把日志归属到具体子测试

表驱动测试中，每一次 t.Run 都会形成一个可筛选的子测试名称。把 t.Parallel 放进闭包，表示这个子测试在完成非并行阶段后参与并行调度；把日志也放在同一个闭包里，日志就和该用例绑定。

package decode_test

import (
    "strings"
    "testing"
)

func TestDecode(t *testing.T) {
    cases := []struct {
        name string
        in   string
        want string
    }{
        {name: "ascii", in: "go", want: "GO"},
        {name: "empty", in: "", want: ""},
        {name: "mixed", in: "Go1", want: "GO1"},
    }

    for _, tc := range cases {
        tc := tc // 固定本轮用例，避免闭包读取变化中的循环变量
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel() // 只让当前子测试进入并行组
            got := strings.ToUpper(tc.in)
            t.Logf("case=%s input=%q want=%q got=%q", t.Name(), tc.in, tc.want, got) // 记录可定位上下文
            if got != tc.want {
                t.Errorf("got %q, want %q", got, tc.want) // 失败时保留同一用例的错误信息
            }
        })
    }
}

这里的 tc := tc 不是日志技巧，而是并行闭包的安全边界：每个子测试持有自己的用例副本。t.Name() 会返回当前测试或子测试名称，适合放到日志里；即使测试框架已经带出层级，显式写出名称仍能让单条日志脱离上下文后保持可读。

用命令控制日志范围

排查时不要一上来就把所有测试改成 fmt.Printf。先用命令控制观察范围：

# 先确认整体结果，成功用例的 t.Logf 默认保持安静
go test ./...

# 需要看并行用例的诊断细节时打开详细输出
go test -v ./...

# 只观察一个子测试，斜杠后的名称对应 t.Run 的名称
go test -run 'TestDecode/mixed' -v ./...

-run 使用测试名称的层级匹配，-v 决定是否显示成功测试的日志。两者组合后，输出范围会从“整个包”缩小到“某个命名子测试”，这比在代码里临时增加全局打印更容易复现。

并行日志最容易踩到的三个边界

• 父测试不要过早清理资源。父测试会等待子测试完成；把共享资源放在父测试中初始化，并用父测试的 t.Cleanup 管理生命周期，比在循环里随手关闭更稳妥。
• 日志顺序不是业务顺序。并行用例的日志可能交错，诊断信息应包含用例名、输入和关键状态，不要依赖“上一行就是上一个用例”的阅读假设。
• 测试返回后不能再写日志。如果另起 goroutine 处理异步结果，要用同步等待或通道让它在子测试返回前结束；否则继续调用 Logf 属于错误。

共享计数器、缓存或临时文件也要单独处理。t.Logf 只负责记录，不提供互斥；必要时使用局部变量、锁或每个子测试独立的资源。这样即使打开 -race，日志也不会掩盖真正的数据竞争。

延伸问答

为什么成功测试看不到 t.Logf？

这是默认行为。用 go test -v 查看成功用例的日志；持续集成环境可以只在失败时保留普通输出，减少噪声。

并行测试的日志会按 t.Run 顺序打印吗？

不要依赖这个顺序。并行测试的执行和完成时机可能不同，应该用子测试名和结构化字段识别每条记录。

能在 goroutine 里直接调用 t.Logf 吗？

日志必须在测试仍然有效时写入。更稳妥的方式是等待 goroutine 完成后再返回；如果异步任务本身需要报告结果，就通过通道把结果交回测试 goroutine。

为什么要把 t.Parallel 放进 t.Run 闭包？

这样并行标记、用例副本、断言和日志都属于同一个命名子测试，边界清楚，也方便用 -run 精确复现。