Go log/slog.SetDefault 怎样让标准 log 统一走结构化日志

如果项目里同时存在旧的 log.Printf 和新的 slog.Info，不必先把所有调用点改写一遍。把一个配置好的 slog.Logger 交给 slog.SetDefault 后，slog 顶层函数会使用它，标准 log 包的默认 Logger 也会把记录送到同一个 Handler。这样可以先统一输出格式，再逐步迁移调用点。

一句话结论：SetDefault 负责连接“默认入口”和“结构化 Handler”，SetLogLoggerLevel 负责控制旧 log 调用转发后的最低级别；它不会自动改造你通过 log.New 创建的独立 Logger。

SetDefault 实际连接了哪些入口

slog.SetDefault(logger) 会替换 slog.Default() 返回的默认 Logger，因此 slog.Info、slog.Warn、slog.Error 等顶层函数都会进入这个 Logger。Go 官方文档还明确说明，调用之后，标准 log 包的默认 Logger（包括 log.Print、log.Printf）也会通过这个 Logger 的 Handler 输出。

这里的“标准 log”特指包级函数使用的默认 Logger，不等于进程中所有 *log.Logger。如果某个依赖自己调用 log.New(writer, prefix, flags)，它仍然保留自己的 Writer、前缀和 flags。

用 JSONHandler 统一旧代码和新代码

迁移时可以先只调整默认 Handler，把输出目的地和结构化格式固定下来。下面的示例保留旧 log.Printf，同时让新代码写入属性字段。

package main

import (
    "log"
    "log/slog"
    "os"
)

func main() {
    // JSONHandler 负责把统一入口写成结构化记录。
    handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
        AddSource: true, // 迁移阶段保留调用位置，便于区分旧入口。
    })
    logger := slog.New(handler)

    // SetDefault 同时切换 slog 顶层函数和标准 log 默认 Logger 的出口。
    slog.SetDefault(logger)

    // 旧调用无需立即改写，仍会进入上面的 Handler。
    log.Printf("legacy request id=%s", "req-17")
    // 新调用可以直接提供键值属性，避免把字段拼进消息文本。
    slog.Info("request accepted", "request_id", "req-17")
}

迁移期间要注意：旧 log.Printf 的文本仍是一条消息，不能凭空恢复成结构化属性；只有新代码显式传入键值对，Handler 才能把它们作为独立字段处理。

为什么旧 log.Printf 的级别可能和预期不同

调用 SetDefault 后，标准 log 默认 Logger 的输出会使用 slog Handler，但转发级别由 slog.SetLogLoggerLevel 控制。迁移时如果希望旧日志进入较低级别，可以先保存旧值，再在限定范围内调整：

// 先保存旧级别，避免库代码改变宿主程序的全局策略。
previous := slog.SetLogLoggerLevel(slog.LevelDebug)
defer slog.SetLogLoggerLevel(previous)

// 旧 log.Printf 会按当前转发策略进入 slog Handler。
log.Printf("cache warmup finished")
// 新 API 仍然可以明确指定自己的级别。
slog.Debug("cache details", "items", 12)

不要把 log.SetFlags 当成 slog 的级别配置。它只影响标准 Logger 原有的日期、时间、文件行号等文本 flags；SetLogLoggerLevel 才是旧调用转发到 slog 时的级别开关。

默认 Logger、独立 Logger 和 NewLogLogger 的区别

可以把迁移对象分成三类：

slog.NewLogLogger 是另一条方向相反的桥：它接收一个 Handler，返回一个旧式 *log.Logger，适合某个只接受 *log.Logger 的组件。不要把它和 SetDefault 混为一谈，前者是显式创建适配器，后者是改变默认入口。

迁移时的三个检查点

• 先确认 Writer：JSONHandler、TextHandler 和旧 Logger 是否最终写到同一个目的地，避免重复采集。
• 再确认级别：旧 log.Printf 的转发级别由 SetLogLoggerLevel 决定，新 API 的级别由调用方法决定。
• 最后确认范围：只切换默认 Logger，不会接管 log.New 创建的实例，也不会把旧消息自动拆成键值字段。

如果这是库代码，通常不要在初始化函数里调用 slog.SetDefault 或改变全局级别；让应用入口决定默认 Handler，库只通过传入的 Logger 或 Handler 输出，更容易测试和组合。

相关问题

SetDefault 后还能恢复原来的默认 Logger 吗？

可以在切换前保存 slog.Default()，结束限定范围后再调用 slog.SetDefault(old)。全局设置要有清晰的生命周期，避免测试之间互相污染。

为什么旧日志没有结构化字段？

log.Printf 只提供格式化文本，SetDefault 只能改变它的输出 Handler，不能推断文本中的字段。需要结构化字段时，应逐步改成 slog.Info 等调用。

NewLogLogger 适合替换所有 log.Printf 吗？

不适合。它用于把指定 Handler 包成一个独立的旧式 Logger；应用级统一出口优先使用 SetDefault，局部适配再使用 NewLogLogger。