Go测试中默认看不到log.Println输出，因为testing.T/B会捕获但不显示log包输出，除非加-v参数；应优先使用t.Log/t.Logf实现强绑定，全局日志需通过buffer捕获后t.Log输出。
Go测试中为什么默认看不到log.Println输出
因为 Go 的 testing.T 和 testing.B 默认会捕获标准日志（如 log.Printf），但不会自动关联到测试日志流；除非你显式调用 t.Log 或 t.Logf，否则 log 包的输出会被静默丢弃（尤其在非 -v 模式下）。这容易让人误以为“日志没打出来”，其实是被屏蔽了。
- 不加
-v参数运行go test时，log.Printf完全不显示 - 加
-v后，log输出会出现在测试结果之后，而非紧贴对应测试用例 -
t.Log的输出则严格绑定测试生命周期，失败时自动打印，-v 下也按顺序展示
如何让日志和测试用例强绑定：优先用t.Log和t.Logf
这是最符合 Go 测试语义的方式。所有输出都会归入该测试实例上下文，支持失败快照、并行测试隔离，且无需额外配置。
func TestSomething(t *testing.T) {
t.Log("开始验证输入参数")
if len(input) == 0 {
t.Logf("输入为空，跳过后续处理")
return
}
t.Log("执行核心逻辑...")
// ...
}
-
t.Log/t.Logf只在当前*testing.T实例有效，子 goroutine 中直接调用会 panic - 若需在 goroutine 中记录，应传入
t并加锁或用t.Helper()配合，但更推荐把日志逻辑收口到主测试流程 - 避免混用
log.Printf和t.Logf，否则输出时间线和归属易混乱
需要全局日志（如 init 或第三方库）时怎么透出
某些场景绕不开 log 包（比如初始化数据库驱动、复用已有工具函数），这时得主动接管日志输出目标。
- 在测试文件开头用
log.SetOutput(t)—— 但不行，*testing.T不实现io.Writer - 正确做法：用
io.MultiWriter把日志同时写到os.Stderr和自定义 writer，后者触发t.Log - 更轻量方案：测试前临时替换
log.SetOutput到一个线程安全的bytes.Buffer，然后在defer t.Log(buf.String())中统一输出（适合单测，不适合并发子测试）
func TestWithGlobalLog(t *testing.T) {
buf := &bytes.Buffer{}
oldOut := log.Writer()
log.SetOutput(buf)
defer func() {
log.SetOutput(oldOut)
if buf.Len() > 0 {
t.Log("捕获到全局日志：", buf.String())
}
}()
someFuncThatCallsLogPrintln() // 内部用了 log.Printf
}
性能敏感场景下要不要关日志
是的，尤其在 Benchmark 或大量子测试中，频繁 t.Logf 会显著拖慢执行速度（字符串格式化 + 内存分配 + 测试框架记录开销）。
- 用
testing.Verbose()做开关：只在-v时输出详细日志 - 避免在循环内无条件调用
t.Log，改用计数器 + 条件触发 - 对纯性能测试（
testing.B），建议完全禁用日志，或仅在b.N == 1时做一次初始化日志
真正难处理的是那些嵌在被测代码深处、又不能改的 log.Printf —— 这时候只能接受它在 -v 下乱序出现，或者重构为可注入的 logger 接口。
