t.Log 输出延迟是设计使然，日志先缓存、测试结束才统一输出，以保证与测试结果的时序可预测；t.Error等失败方法会立即刷新并追加堆栈，而defer中t.Log可能静默丢失。
为什么 t.Log 输出总在测试结束后才刷出来
t.Log 的输出不是实时打印到终端的，而是先写入内部缓冲区，等测试函数返回后统一输出。这不是 bug，是设计使然——Go 测试框架需要确保日志与测试结果（pass/fail）的时序可预测，避免并发写 stdout 导致混乱。
- 缓冲行为只发生在
t.Log、t.Logf，t.Error/t.Fatal等失败方法会立即 flush 缓冲区并附加堆栈信息 - 如果测试 panic 或被
t.Fatal中断，未 flush 的t.Log内容会丢失（常见于 defer 里调用t.Log却没触发 flush） - 子测试（
t.Run）也各自维护独立缓冲区，父测试结束不会触发子测试缓冲区 flush
如何让 t.Log 实时看到输出（调试急需时）
没有官方 API 强制 flush t.Log 缓冲区，但有可靠替代方案：绕过测试日志系统，直接写 os.Stderr。
- 用
fmt.Fprintln(os.Stderr, "debug:", x)替代t.Log(x)，输出立刻可见，且不干扰测试结果判定 - 注意：不要混用
fmt.Println（它写os.Stdout），某些 CI 环境默认不捕获 stdout，容易漏掉 - 上线前务必删掉或注释掉这些临时输出，它们不属于测试逻辑，也不受
-v控制
t.Error 和 t.Log 混用时的顺序陷阱
日志和错误输出在终端显示的顺序 ≠ 代码执行顺序，尤其当 t.Error 触发后还会追加 goroutine 堆栈和测试耗时——这些内容会插在你最后一条 t.Log 和 t.Error 文本之间。
- 错误发生前的
t.Log("before")会出现在最终输出顶部，但t.Log("after")在t.Error后调用则根本不会输出（因为t.Error不终止执行，但后续日志可能被截断或淹没） - 更危险的是：在
defer中调用t.Log，若测试已因t.Fatal结束，该日志会被静默丢弃，毫无提示 - 验证顺序最简单的方法：加时间戳，比如
t.Log(time.Now().Format("15:04:05.000"), "msg")
子测试中 t.Log 的作用域和生命周期
每个 t.Run 创建的子测试都有自己的 *testing.T 实例，缓冲区完全隔离。父测试的 t.Log 和子测试的 t.Log 不会交叉，但容易误判“为什么这里没输出”。
立即学习“go语言免费学习笔记（深入）”；
- 子测试内调用
t.Log，只会在该子测试结束时 flush；若子测试被t.Skip跳过，则其所有t.Log全部丢弃 - 不要在子测试外层循环里反复用同一个
t调用t.Log，必须在t.Run函数体内调用 - 想看子测试中间状态？仍推荐
fmt.Fprintln(os.Stderr, ...)，或者用t.Logf("step %d: %v", i, result)并确保子测试实际运行（非 skip）
