Go log/slog.NewLogLogger 怎样适配旧式 Logger 接口

如果旧模块大量使用 log.Printf、log.Println 或者接收 *log.Logger，但新日志链路已经统一到 slog.Handler，不必立刻重写所有调用点。slog.NewLogLogger 会返回一个旧式 *log.Logger，它的 Output 调用会把记录交给指定的 Handler。

官方地址：https://pkg.go.dev/log/slog#NewLogLogger

最小方案是先创建 TextHandler 或 JSONHandler，再用 slog.NewLogLogger(handler, slog.LevelInfo) 得到兼容旧 API 的 logger。第二个参数决定桥接记录使用的固定级别；旧式格式化参数仍然是消息文本，不会自动变成结构化字段。

先划清旧接口和新处理器的边界

log.Logger 负责接收旧式调用并形成文本消息，slog.Handler 负责处理带有级别、消息和属性的 slog.Record。NewLogLogger 处在两者之间：它解决的是接口兼容，不是把旧代码凭空改造成完整的结构化日志 API。

这条边界决定了迁移策略：调用点可以先保持不变，输出处理器可以先统一；需要业务字段时，再把关键调用点逐步迁移到 slog.Info、slog.Error 或 Logger.LogAttrs。

用 NewLogLogger 创建兼容旧代码的 logger

下面的写法把旧式 logger 指向文本 Handler。代码中的中文注释只解释关键配置和资源归属，不改变旧 API 的调用方式。

package main

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

func main() {
    // TextHandler 负责把结构化记录写到标准错误输出。
    handler := slog.NewTextHandler(os.Stderr, nil)

    // 第二个参数给桥接产生的记录指定固定级别。
    legacy := slog.NewLogLogger(handler, slog.LevelInfo)

    // 旧式调用点无需改成 slog API 即可复用新的 Handler。
    legacy.Printf("cache refresh: key=%s", "profile")
    legacy.Println("worker is ready")

    // 保留 log 包类型，便于把 legacy 传给只接受 *log.Logger 的旧模块。
    var _ *log.Logger = legacy
}

这里的 handler 只负责输出，不需要手动关闭；os.Stderr 也不由这段代码创建，因此不要在适配层里擅自关闭它。若旧模块要求的是 *log.Logger，直接传入 legacy 即可。

级别参数怎么选，Printf 的字段又该怎么处理

NewLogLogger 的 level 是桥接记录的级别，不是一个动态的过滤开关。旧式 Printf、Println 没有 slog.Level 参数，所以同一个桥接 logger 发出的记录会使用创建时指定的级别。

如果旧模块承载的是普通运行信息，可以使用 slog.LevelInfo；如果它只输出异常，使用 slog.LevelError 更容易和现有告警规则对齐。不要为了“看起来更结构化”把所有旧日志都标成 Error，否则会让下游误判故障。

// 旧式格式化参数会先组成 message 文本，不会自动生成 slog.Attr。
legacy.Printf("user=%s retry=%d", userID, retryCount)

// 需要可检索字段时，逐步把关键调用迁移到 slog。
logger.Info("retry scheduled",
    "user_id", userID,
    "retry_count", retryCount,
)

因此可以把桥接看成“兼容层”，把显式属性看成“迁移层”。两者可以共存，但不要在同一处同时打印一遍旧文本和一遍新记录，避免重复采集。

让 Handler 决定文本还是 JSON 输出

桥接层只依赖 slog.Handler 接口，输出格式由 Handler 的具体实现决定。开发环境可以用 TextHandler，需要被日志系统按字段解析时可以用 JSONHandler。两者都能接到同一个 NewLogLogger。

package main

import (
    "log/slog"
    "os"
)

func newLegacyLogger(jsonOutput bool) *slog.Logger {
    opts := &slog.HandlerOptions{
        // 让处理器只接收 Info 及以上级别，避免旧日志过度放大。
        Level: slog.LevelInfo,
        // 生产环境可按需要打开来源字段；它会增加输出体积。
        AddSource: false,
    }

    var handler slog.Handler
    if jsonOutput {
        handler = slog.NewJSONHandler(os.Stdout, opts)
    } else {
        handler = slog.NewTextHandler(os.Stderr, opts)
    }

    // 返回兼容旧 log.Logger 的对象，Handler 仍由调用方选择。
    return slog.New(handler)
}

上面这个辅助函数返回的是 *slog.Logger，如果目标是旧模块，应在最后改为 slog.NewLogLogger(handler, slog.LevelInfo)。关键点是不要把 Handler 的筛选级别和桥接记录的固定级别混为一谈：前者决定 Handler 是否处理，后者决定记录本身标记成什么级别。

发布前检查这四个兼容点

1. 确认旧模块真正依赖的是 *log.Logger，而不是自定义的带有额外方法的接口。
2. 确认桥接级别与旧日志语义一致，普通状态不要误标成 Error。
3. 确认 Printf 里的键值仍是文本；需要检索字段的热点调用要单独迁移到 slog 属性。
4. 确认 TextHandler、JSONHandler 的输出目标由外部生命周期管理，适配层不关闭不属于自己的 Writer。

回滚也很简单：保留旧的 *log.Logger 构造方式，把依赖注入的实现替换回原对象即可。桥接层最好集中在初始化位置，避免每个业务包各自创建一套 Handler。

常见问题

NewLogLogger 会把 Printf 的 key=value 变成结构化字段吗？

不会。旧式格式化调用首先形成消息文本；需要稳定字段时，应迁移到 slog 的参数或 Attr API。

第二个参数能不能根据每条旧日志动态变化？

不能通过同一个旧式 logger 的调用参数动态传入。需要不同级别时，创建不同桥接对象，或者直接迁移到 slog 的显式级别方法。

TextHandler 和 JSONHandler 可以在运行中切换吗？

可以通过重新构造并注入新的 Handler 实现切换，但要把 Writer 生命周期、重复输出和下游解析规则一起纳入发布计划。

总结来说，slog.NewLogLogger 适合做渐进式迁移的兼容边界：旧调用点先保持稳定，Handler 先统一，字段化日志再按业务价值逐步改造。