go test -v 输出测试函数中 t.log/t.logf 的结构化日志及失败信息，每行带测试名前缀（如=== run testadd），子测试层级清晰；fmt.println 无上下文、不被统一管理，易乱序丢失。
go test -v 输出的到底是什么内容
它不是简单地把 fmt.Println 打印出来就完事，而是把测试函数执行过程中的所有 t.Log、t.Logf 和失败时的 t.Error/t.Fatal 信息，按测试顺序结构化输出，并在每行前加上测试名前缀（如 === RUN TestAdd）。没有 -v 时，这些日志默认被静默丢弃。
-
go test默认只显示失败测试的错误信息；加-v后，无论成功失败，所有t.Log都可见 - 只有在测试函数内部调用
t.Log或t.Logf，才会出现在-v输出里；fmt.Println不受控制，会混在终端其他输出中，且不带测试上下文 - 子测试（
t.Run）也会被单独标记，层级清晰，适合调试参数组合场景
为什么 t.Log 比 fmt.Println 更可靠
因为 t.Log 的输出和测试生命周期绑定：它只在测试运行期间生效，会被 go test 统一捕获、格式化、按需过滤；而 fmt.Println 是无状态的进程级输出，可能出现在测试开始前、结束后，甚至并发测试中错乱交错。
- 在并行测试（
t.Parallel()）中，fmt.Println完全不可控，多 goroutine 写 stdout 会严重乱序；t.Log自动加锁并打上 goroutine ID 和测试名前缀 - CI 环境中，
go test -v日志可直接用于问题定位；裸fmt输出可能被截断、丢失或无法关联到具体测试用例 -
t.Log在测试通过时不输出（除非加-v），天然适配“默认安静、需要时展开”的调试习惯
常见误用：-v 用了但没看到日志？
大概率是写错了日志调用位置或方式。最典型的是在测试函数外、或在 init()、或在 main() 里用 fmt 打印——这些和 go test 的测试驱动完全无关。
- 确保日志语句在
func TestXxx(t *testing.T)函数体内，且使用t.Log而非fmt - 检查是否漏了
-v：仅go test或go test -run=TestXxx不加-v，日志不会出现 - 注意作用域：在
t.Run("sub", func(t *testing.T) {...})内部，必须用传入的子t调用t.Log，不能用外层t - 避免提前 return：如果在
t.Log前触发了t.Fatal，后续日志不会执行
配合 -run 和 -failfast 提升定位效率
go test -v 单独用容易信息过载，实际调试时应组合过滤。比如只想看某个测试的详细流程，或让失败立刻终止，避免冗余执行。
-
go test -v -run=^TestParseJSON$：用正则精确匹配单个测试，避免其他测试日志干扰 -
go test -v -failfast：第一个失败就停，防止后续测试掩盖真正问题，尤其适合有副作用或共享状态的测试 -
go test -v -count=1：禁用缓存，强制重跑（默认会跳过未改文件），确保日志反映最新逻辑 - 在 VS Code 中，点击测试旁的 ▶️ 运行时，默认不带
-v；要看到日志得手动改配置或终端执行
t.Log 和 fmt 的根本差异。 
