Go slog.NewLogLogger 怎么接入旧日志库：级别映射与结构化字段边界

老项目里经常有一条尴尬的日志链：新模块已经使用 log/slog，第三方库却只接受一个 *log.Logger。这时不必立刻改掉所有旧调用，slog.NewLogLogger 可以把传统日志入口桥接到指定的 slog.Handler，但桥接级别和默认日志器的关系必须先验证清楚。

把兼容范围限定在“旧入口如何进入新 Handler”：用 slog.NewLogLogger 适配 log.Logger，用第二个参数决定桥接记录的级别；不要把它误认为会自动改写旧日志调用的参数结构。

旧库只收 *log.Logger，为什么不能直接塞入 slog.Logger

问题通常出现在初始化代码里：旧库的配置字段类型是 *log.Logger，而应用主链路已经有一个 slog.Logger。两者不是同一个接口层，直接传入会在编译期失败；即使把旧库保留为独立输出，也会让日志格式、级别和采集目标分叉。

这里更适合做一个窄适配。slog.Logger 面向结构化日志调用，slog.Handler 承担具体记录处理；log.Logger 仍负责接收旧式的 Print、Printf 或 Output 调用。

最小桥接：让 log.Logger 的输出进入 slog.Handler

下面的示例把旧日志入口送进 JSON handler。桥接器的第二个参数设为 slog.LevelInfo，表示这些旧式调用在新链路里统一按 Info 记录。

package main
import ("log"; "log/slog"; "os")
func main() {
    handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{Level: slog.LevelInfo})
    legacy := slog.NewLogLogger(handler, slog.LevelInfo)
    legacy.Printf("order_id=%d status=%s", 731, "paid")
}

legacy 的静态类型仍是 *log.Logger，所以依赖旧 API 的组件可以继续使用它；真正输出时，slog.NewLogLogger 会把这次调用转成一条 Record 并交给 slog.Handler。旧格式字符串里的键值不会自动变成结构化属性，它们仍然属于 message 文本。

图中三段关系对应代码中的真实对象：log.Logger 接收旧调用，slog.NewLogLogger 建立适配，slog.Handler 负责最终处理。

级别怎么选：固定桥接级别与 Handler 过滤是两道门

很多混乱来自把两个“级别”混成一个。NewLogLogger(handler, level) 的 level 是桥接出来的每条记录使用的级别；JSON handler 的 HandlerOptions.Level 则是处理器自己的最低接收级别。

如果旧组件的所有输出都用 legacy.Printf，却希望 Debug 日志在开发环境可见，可以创建一个 Debug 级别的桥接器：

debugLegacy := slog.NewLogLogger(handler, slog.LevelDebug)
debugLegacy.Print("cache probe")

但这不会绕过 Handler 的最低级别。如果 HandlerOptions.Level 仍是 slog.LevelInfo，这条 Debug Record 依然会被过滤。

SetDefault 之后，默认 log.Printf 又走哪条路

调用 slog.SetDefault 后，顶层 slog.Info 等调用使用新的默认 logger；标准库也会把默认 log.Logger 的输出接到这个 logger 的 Handler，级别由 slog.SetLogLoggerLevel 控制。

logger := slog.New(handler)
slog.SetDefault(logger)
slog.SetLogLoggerLevel(slog.LevelDebug)
log.Printf("legacy default path")
slog.Debug("new default path")

这条默认路径和手工创建的 slog.NewLogLogger 不是一回事：前者由默认 logger 和 SetLogLoggerLevel 管理，后者在创建时已经拿到了指定的 Handler 与 level。排查时先看旧库到底拿到的是哪个 *log.Logger。

一组小测试就能验收兼容边界

使用 bytes.Buffer 作为输出，检查 JSON 中的 msg、level 和旧格式文本即可。测试至少覆盖旧入口、指定 Handler 和级别过滤。

handler := slog.NewJSONHandler(&buf, &slog.HandlerOptions{Level: slog.LevelDebug})
legacy := slog.NewLogLogger(handler, slog.LevelInfo)
legacy.Printf("order_id=%d", 731)
if !strings.Contains(buf.String(), `"level":"INFO"`) { t.Fatal("legacy log was not bridged") }

需要可检索字段时，应在新代码中直接使用 slog.Int("order_id", 731)，不要依赖桥接器猜格式。

相关问题：迁移时最容易踩的三个坑

NewLogLogger 会自动解析键值对吗

不会。它把旧调用变成 Record，格式化结果仍主要是消息文本。

为什么 Debug 桥接器创建了，输出还是看不到

先检查 Handler 的最低级别。桥接级别是 Debug，但 Handler 仍可能按 Info 过滤。

SetLogLoggerLevel 会修改已创建的桥接器吗

不会。它主要用于标准库默认 log logger 与 slog 默认 logger 的连接路径。

落地前的选择清单

• 旧依赖只需要 *log.Logger：用 slog.NewLogLogger 做窄适配。
• 新代码需要可检索属性：直接调用 slog.Logger 或 LogAttrs。
• 日志不见了：分别检查桥接级别、HandlerOptions.Level 和 SetLogLoggerLevel。
• 上线前用内存缓冲区验证旧入口、级别和 message 内容，再接真实输出。