应重定向全局 log 输出至 bytes.Buffer 并恢复，因 log.Printf 默认写入 os.Stderr；不可仅用 log.New 创建局部 logger，因第三方库等仍调用全局 logger；log.SetOutput 非线程安全，禁用并行或改用可注入 logger 更稳妥。
如何捕获 log.Printf 的输出进行断言
Go 标准库的 log 包默认写入 os.Stderr，无法直接用 t.Log 或字符串比较验证。必须重定向其输出目标为内存缓冲区。
关键做法是用 bytes.Buffer 替换 log.SetOutput，并在测试前后恢复原始输出，避免干扰其他测试：
func TestLogOutput(t *testing.T) {
var buf bytes.Buffer
oldOut := log.Writer()
log.SetOutput(&buf)
defer log.SetOutput(oldOut) // 必须恢复，否则后续测试日志会丢失
log.Printf("user %s logged in", "alice")
output := buf.String()
if !strings.Contains(output, "alice") {
t.Errorf("expected 'alice' in log, got %q", output)
}
}
为什么不能直接用 log.New 创建独立 logger 就完事
很多代码用 log.New 创建局部 logger，看似隔离，但若业务逻辑中仍调用了全局 log.Printf（比如第三方库、或漏改的旧代码），这些日志依然会打到 os.Stderr，导致断言失败或测试不稳定。
真正安全的做法是：统一拦截全局 logger 输出，并确保被测代码只使用你可控的日志入口。若必须混合使用，需明确区分：
立即学习“go语言免费学习笔记（深入）”；
-
log.Printf→ 走全局 logger → 必须log.SetOutput拦截 - 自定义
*log.Logger实例 → 只影响该实例的Printf调用 → 可单独设bytes.Buffer作为其输出
混用时最容易漏掉对全局 logger 的重定向，结果日志“消失”或“出现在终端”，测试看似通过实则没覆盖。
log.SetOutput 在并行测试中是否线程安全
不安全。log.SetOutput 是全局操作，如果多个 t.Parallel() 测试同时修改它，会出现竞态：A 测试刚设完 buffer，B 测试立刻覆盖成另一个 buffer，A 的断言就拿不到自己想要的日志。
解决方案只有两个：
- 所有涉及
log.SetOutput的测试禁用并行：t.Parallel()不要加 - 彻底放弃全局 logger，改用可注入的 logger 接口（如
func(string, ...interface{})），在测试中传入带 buffer 的闭包
后者更推荐，尤其在新项目中——它让日志行为显式可控，也规避了标准库的全局状态陷阱。
测试中验证日志级别或格式是否符合预期
标准 log 包本身不提供日志级别（如 DEBUG/INFO/WARN），但常见做法是通过前缀（log.SetPrefix("[WARN] ")）或标志（log.LstdFlags | log.Lshortfile）模拟。验证时要注意这些配置是否生效：
- 启用
log.LstdFlags后，输出开头会有时间戳，例如"2024/05/20 14:22:33 user alice logged in" - 启用
log.Lshortfile后，会多出文件名和行号，例如"test.go:12: user alice logged in" - 前缀内容会拼在每条日志最前面，且**不带空格自动补全**，需手动加空格避免粘连
因此断言时别只查关键词，要检查完整结构。比如设了 log.SetPrefix("[INFO] ")，就得 assert strings.HasPrefix(output, "[INFO] user alice")，而不是只查 "user alice"。
