17370845950

应重定向全局 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 输出，并确保被测代码只使用你可控的日志入口。若必须混合使用，需明确区分：

• 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 后，输出开头会有时间戳，例如 "2025/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"。