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，而是设计选择——避免成功测试产生大量干扰日志。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 运行测试时加
-v参数强制显示所有日志：go test -v
- 若只对某个测试启用详细日志，可在命令中指定测试名：
go test -v -run=TestMyFunc
- 注意：即使加了
-v，t.Log仍只在当前测试函数内输出；它不会跨测试传播，也不影响其他t.Parallel()子测试的日志可见性
如何让 t.Log 在失败时自动带上行号和调用栈
Go 标准库不提供自动行号标记，但可通过包装函数或自定义 helper 实现类似效果。关键是利用 runtime.Caller 获取调用位置。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要直接在测试里反复写
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.Log会被框架静默丢弃（符合预期） - CI 环境中，某些测试报告工具（如 gotestsum）只解析
t.Log行为，忽略fmt输出
例外场景：调试极早期初始化（比如 init() 函数、全局变量赋值），此时 *testing.T 尚未构造，只能用 fmt 或 log.Printf，但这类日志不属于“测试日志”，应尽快移除
如何在子测试（t.Run）中控制日志粒度
子测试共享父测试的 *testing.T 实例，但 t.Log 输出天然绑定到当前子测试作用域。关键点在于：子测试失败时，只会打印该子测试内的 t.Log，不会带出父测试或其他子测试的日志。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
t.Run内部调用t.Log是安全且推荐的，无需额外处理 - 如果想区分层级，可手动加前缀：
t.Logf("step1: got response %v", resp) - 避免在子测试里调用
t.Fatal后还写t.Log—— 它不会执行，Go 会直接终止该子测试 - 注意：子测试中调用
t.Setenv或t.TempDir不会影响日志行为，但可能改变实际输出内容（比如环境变量影响日志格式）
日志本身没有“嵌套”概念，所谓“子测试日志”只是输出文本带上了子测试名称前缀，由测试框架自动添加。
