testing.verbose() 返回bool值指示是否启用-v模式，不控制日志输出行为本身；t.log()等需手动配合该函数使用才能条件输出，且不受其影响的t.error()等始终显示。
testing.Verbose() 是什么，它真能控制输出吗
testing.Verbose() 不是开关函数，它不控制日志打印行为本身，只返回一个 bool 值：当前测试是否以 -v 模式运行。Go 的 t.Log() 和 t.Logf() 默认静默，只有在 testing.Verbose() 为 true 时才实际输出——但这个“控制”是靠你手动判断、手动调用实现的，不是框架自动拦截。
常见误解是以为加了 t.Log("xxx") 就能在 go test -v 时自动显示，其实它一直会执行（包括非 -v 模式），只是输出被抑制了；而 t.Error()、t.Fatal() 这类断言输出不受 testing.Verbose() 影响，始终可见。
怎么安全地添加条件日志输出
典型做法是在测试函数里先检查 testing.Verbose()，再决定是否调用 t.Log()。注意：不要在循环或高频路径中无条件调用 t.Log()，即使没输出，构造日志字符串也有开销。
- ✅ 推荐写法：
if testing.Verbose() { t.Logf("processing item %d, key=%s", i, key) } - ❌ 避免写法：
t.Logf("processing item %d, key=%s", i, key) // 无论 -v 是否开启都拼接字符串 - ⚠️ 注意边界：如果日志内容涉及副作用（比如调用
time.Now()或读文件），必须包在if testing.Verbose()内，否则测试行为在 -v 和非 -v 下不一致
为什么 t.Log 在 -v 下也不显示？常见漏点
最常踩的坑是：写了 t.Log()，也加了 -v，但控制台还是没看到输出。原因通常是：
- 测试函数已提前失败（例如触发了
t.Fatal()），后续t.Log()不再执行 - 日志写在
defer里，而defer在测试函数 return 后才执行，此时测试上下文可能已销毁，日志被丢弃 - 用了
fmt.Println()而非t.Log()—— 前者完全绕过测试框架，不受-v控制，且在并行测试中容易混序 - 测试文件名不符合
*_test.go规则，或函数名没以Test开头，导致根本没被识别为测试
和 -benchmem、-run 等标志共存时要注意什么
testing.Verbose() 只响应 -v，和其他 flag 无关。但组合使用时有隐含影响：
- 跑基准测试时加
go test -bench=. -v，testing.Verbose()仍为true，但BenchmarkXxx函数里调用t.Log()会被忽略（*testing.B不支持日志输出）——别在 benchmark 函数里用它 -
-run过滤测试后，只要匹配到的测试函数执行了，testing.Verbose()行为不变 - 并发测试（
t.Parallel()）中，t.Log()输出会按执行顺序交错，-v 下可读性差；若需清晰追踪，建议加前缀如t.Logf("[goroutine %d] ...", id)
真正容易被忽略的是：Verbose 的判定发生在测试启动时，一旦进程开始运行，修改环境变量或重设 flag 不会影响已启动的测试函数里的 testing.Verbose() 返回值。
