t.Log在CI中默认静默，仅失败时显示；需加-v参数或用testing.Verbose()控制输出，避免panic和冗余日志。
测试中用 t.Log 打印调试信息，为什么 CI 里看不到？
因为 t.Log 输出默认被静默，只有测试失败时才会展开显示。这不是 bug，是设计：避免成功测试污染日志流。
实操建议：
- 本地调试时加
-v参数运行：go test -v，所有t.Log都会实时输出 - CI 中若需始终看到日志，可统一加
-v；但更推荐只在必要时输出，比如用if testing.Verbose()控制条件打印 - 别依赖
t.Log做断言或状态检查——它不阻断执行，也不影响测试结果
t.Logf 格式化字符串的坑：参数数量不匹配直接 panic
Go 的 t.Logf 和 fmt.Printf 行为一致：格式动词（如 %s、%d）和参数个数必须严格对应，否则测试进程会 panic，报错类似 testing: test executed panic: fmt: %!s(MISSING)。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 复制粘贴旧日志行，删了某个变量但忘了删对应
%s - 传入
nil指针给%s，导致运行时报string of nil pointer - 用
%v打印结构体时，嵌套过深触发无限递归（尤其含循环引用）
建议写法：t.Logf("user id: %d, name: %q", u.ID, u.Name) —— 显式指定类型，比全用 %v 更安全可控。
测试日志该记什么？不该记什么？
日志目标不是“把所有东西打出来”，而是帮你在失败时快速定位“哪里不对”“输入是什么”“中间状态如何”。
推荐记：
- 关键输入参数（尤其是非默认值）：
t.Logf("input: %+v", req) - 外部依赖返回值（如 mock 调用结果）：
t.Logf("db.Find() returned: %v", users) - 分支判断依据：
t.Logf("skipping validation because feature flag is off")
避免记：
- 循环内每次迭代都
t.Log（性能差，日志爆炸）—— 改用计数或采样，比如只打第 1 / 最后 1 次 - 敏感信息（token、密码、用户手机号），即使测试用假数据也要过滤
- 与当前测试逻辑无关的全局状态（如时间戳、随机 seed），除非它直接影响行为
并行测试（t.Parallel()）下日志顺序不可靠
多个 t.Parallel() 测试函数并发执行时，t.Log 输出的顺序和代码执行顺序不一致。这不是 bug，是并发日志的天然限制。
这意味着：
- 不能靠日志顺序推断执行流程（比如 A 日志在 B 日志前面，不代表 A 先执行完）
- 不要在日志里写“开始处理…”“结束处理…”这类隐含时序的描述
- 如果真要追踪并发行为，改用唯一 ID 标记每条日志：
t.Logf("[req-%d] fetched %d items", reqID, len(items))
最常被忽略的一点：日志本身不是同步原语，它不提供任何执行顺序保证——哪怕你加了 time.Sleep，也不能让日志变“有序”。
