Go testing.T.Logf 怎样格式化多行诊断信息

Go 测试里需要同时记录用例名、期望值和实际值时，testing.T.Logf 比字符串拼接更合适。它采用类似 fmt.Printf 的格式串和参数，把诊断内容写入当前测试的错误日志；默认情况下，测试通过时日志不会显示，测试失败或使用 -test.v 时才会看到。

多行信息也不需要换成普通输出函数：把换行明确写进格式串即可。需要注意的是，Logf 负责记录诊断，不负责让测试失败；真正的断言仍然要由 t.Errorf、t.Fail 等方法完成。

官方文档：https://pkg.go.dev/testing#T.Logf

最小写法：用格式串保留关键上下文

先把一条日志拆成“固定字段 + 动态参数”。占位符的类型必须和参数匹配，这样失败时能直接看出是哪一个用例、哪个字段不符合预期。

package logftest

import "testing"

func TestStatus(t *testing.T) {
	name := "create-order"
	want, got := 201, 503

	// Logf 只记录诊断信息；真正让测试失败的是后面的断言。
	t.Logf("case=%s want_status=%d got_status=%d", name, want, got)
	if got != want {
		// 失败消息保留同一组字段，便于 CI 日志检索。
		t.Errorf("status mismatch: want=%d got=%d", want, got)
	}
}

这里的格式串只负责描述输出模板，%s 接收字符串，%d 接收整数。不要把所有值先用 fmt.Sprintf 拼成一条字符串再传给 Log，否则格式和参数的对应关系会分散到两处。

多行诊断：把差异分段而不是堆成一行

比较 JSON、SQL 或长文本时，一行日志通常不容易阅读。可以在格式串中显式加入 \n，并为每个区块保留清晰的标签。Logf 会在没有结尾换行时自动补一个换行，但中间的换行仍然要由格式串或参数提供。

package logftest

import "testing"

func TestPayload(t *testing.T) {
	want := "{\"enabled\":true}"
	got := "{\"enabled\":false}"

	// 显式分隔 want 和 got，长文本不会和字段名粘在一起。
	t.Logf("payload diff:\nwant:\n%s\ngot:\n%s", want, got)
	if got != want {
		// Logf 便于阅读，Errorf 负责把测试标记为失败。
		t.Errorf("payload is different")
	}
}

如果内容本身可能包含换行，建议保持“字段名独占一行”的格式。不要把用户输入直接当作格式串，例如 t.Logf(got)；正确方式是把它当作参数传入，例如 t.Logf("got:\n%s", got)。

子测试与并发：日志要带自己的识别信息

在表驱动测试或并行子测试里，多个日志可能靠得很近。t.Name() 能返回当前测试或子测试的完整名称，把它放进日志可以降低阅读时对输出顺序的依赖。

package logftest

import "testing"

func TestCases(t *testing.T) {
	cases := []struct {
		name string
		in   int
	}{
		{name: "small", in: 1},
		{name: "large", in: 100},
	}

	for _, tc := range cases {
		tc := tc // 为每个子测试固定当前用例值。
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel()
			// 名称和输入值都在消息中，避免依赖并发输出的先后顺序。
			t.Logf("test=%s input=%d", t.Name(), tc.in)
		})
	}
}

测试报告方法可以由多个 goroutine 同时调用，但这不代表日志行会按业务顺序排列。并发场景应把上下文放进每条消息，不要用“上一行一定属于这个用例”的假设来解析日志。

为什么测试通过时看不到 Logf 输出

这是 testing 包的输出策略，不是 Logf 没有执行。普通测试默认隐藏成功用例的日志；要在测试成功时查看它，使用 -test.v 对应的命令行写法：

# -run 只筛选目标测试，-v 显示成功测试的日志。
go test -run '^TestPayload$' -v ./...

# 不加 -v 时，通常只看到失败测试的日志和测试结果。
go test -run '^TestPayload$' ./...

命令中的正则只是筛选示例，实际项目可以换成包路径或更窄的测试名称。不要把“没有日志”直接判断为“代码没有走到 Logf”，先确认测试是否成功以及命令是否启用了详细输出。

异步日志的生命周期边界

Logf 必须在测试仍然存活时调用。若测试函数已经返回，后台 goroutine 再写日志就属于生命周期错误；因此异步任务要先等待结束，再让测试函数返回。

package logftest

import (
	"testing"
)

func TestAsyncLog(t *testing.T) {
	done := make(chan struct{})
	go func() {
		defer close(done) // 通知测试主 goroutine：日志已经写完。
		// 这个调用发生在 TestAsyncLog 返回之前，因此仍在有效生命周期内。
		t.Logf("worker finished: job=%d", 7)
	}()

	

如果异步任务可能卡住，应为等待过程增加超时并在超时分支中调用失败方法；不要为了“留下日志”而让测试永久阻塞。对并发任务来说，完成信号、取消信号和日志调用应当属于同一套生命周期设计。

Logf 的几个常见误区

• 把 Logf 当断言：它只记录信息，不会改变测试成败；比较失败仍要调用 Errorf 或其他失败方法。
• 忽略格式参数：%d、%s 等占位符应与参数类型对应，复杂对象可使用 %+v 先输出字段名。
• 把动态文本当格式串：动态内容作为参数传入，避免文本中的百分号被误当成占位符。
• 依赖并发输出顺序：为每条消息带上 t.Name()、请求 ID 或用例名，把日志设计成可独立阅读的记录。
• 在测试结束后写日志：等待 goroutine 或任务完成后再返回，不能把测试对象交给生命周期不受控的后台任务。

相关问题

Logf 和 Log 有什么区别？

Logf 使用格式串和参数，适合结构化地拼出诊断信息；Log 使用默认格式直接记录参数。需要固定字段布局时优先选择 Logf。

为什么要同时写 Logf 和 Errorf？

Logf 可以记录请求、输入和上下文，Errorf 则明确告诉测试框架断言失败。两者职责不同，组合使用比把所有内容塞进一条失败消息更容易维护。

多行字符串是否需要手动在末尾加换行？

格式串没有结尾换行时，测试日志会自动补一个；但多行内容内部的分段换行仍要显式写入格式串或参数。