Go 日志slog Attr 中的 error 没有展开怎么办

slog 的 Attr 放入 error 后没有自动展开，通常不是属性丢失。使用标准 JSONHandler 时，普通 error 默认按 Error 方法返回的文本记录；它不会替应用遍历 Unwrap 链，也不会自动拆出业务错误码、操作名和堆栈。需要可查询字段时，应显式构造 Group，或让传入的值实现 LogValuer。

这篇讨论从“错误字符串”迁移到“受控错误对象”的日志结构调整，不把它描述成某个新版本突然引入的回归。示例使用 Go 1.21 起提供的 log/slog API；若使用第三方 Handler，应另外看该 Handler 的字段编码约定。官方文档：https://pkg.go.dev/log/slog。

先确认期望的是错误字符串还是可查询字段

假设目录服务返回一个包含 Code、Op 和 Cause 的业务错误，调用方把它作为 slog.Any 的值。期望日志能查询错误码，但输出只看到一句错误文本。这里要先分清：Attr 只是属性的键和值，最终如何编码由 Handler 决定；slog.Any 不表示“递归展开一切 Go 对象”。

标准 JSONHandler 对直接作为属性值的普通 error 有专门处理：在它没有实现 json.Marshaler 的情况下，采用 Error 文本。自定义 json.Marshaler 属于另一条编码约定，不等于 error 被普遍反射展开。错误藏在普通结构体字段或切片里面时，也不要据此推定会逐层得到同样的错误文本处理。

如果原先日志库提供自动堆栈、特殊错误编码器或错误链展示，这些是原库的能力，不能仅仅替换成 slog.Any 就认为语义完全相同。迁移前先列出真正依赖的字段，而不是把日志看起来短了都归咎于 Attr。

迁移前把 error 字段的类型约定写清楚

这里选择新增 error_detail 对象，而不改已有 error 字符串字段的类型。已有采集系统可能把 error 映射为字符串，突然改成对象会影响索引、看板和查询。是否短期双写取决于日志平台规则；若继续保留旧文本字段，也必须保证它已经脱敏。

静态关系可以分成“日志输入组”和“编码职责组”。日志输入组包含“原始错误、属性值、日志记录”；编码职责组包含“Handler、错误文本、结构化分组”。原始错误可以成为属性值，日志记录持有属性，Handler 接收日志记录。错误文本与结构化分组是两种不同的展示结构，是否输出哪一种必须由值的约定及 Handler 决定。

用显式错误适配器输出受控分组

下面使用一个专门的 errorView 适配器。它接收原错误，通过 errors.As 识别允许的业务类型，只输出固定安全文本和白名单内的 code、op，不递归写出 Cause。它的职责是展示，不替换业务错误本身。

package main

import (
    "context"
    "errors"
    "fmt"
    "log/slog"
    "os"
)

// 业务错误保存原始原因，但不把它直接全部写进日志。
type serviceError struct {
    Code string
    Op string
    Cause error
}

func (e *serviceError) Error() string {
    if e == nil {
        return "服务错误为空"
    }
    return "服务操作失败"
}

func (e *serviceError) Unwrap() error {
    if e == nil {
        return nil
    }
    return e.Cause
}

// 适配器只负责日志展示，不改变原来的错误链。
type errorView struct {
    err error
}

func (v errorView) LogValue() slog.Value {
    if v.err == nil {
        return slog.StringValue("无错误")
    }
    attrs := []slog.Attr{
        // 使用固定安全文本，不直接记录可能含凭据的 Error 字符串。
        slog.String("message", "操作未完成"),
    }
    var target *serviceError
    if errors.As(v.err, &target) && target != nil {
        // 示例只允许这两个已知代码和操作名进入索引字段。
        if target.Code == "UPSTREAM_TIMEOUT" {
            attrs = append(attrs, slog.String("code", target.Code))
        }
        if target.Op == "load_catalog" {
            attrs = append(attrs, slog.String("op", target.Op))
        }
    }
    return slog.GroupValue(attrs...)
}

func main() {
    logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
    inner := &serviceError{
        Code: "UPSTREAM_TIMEOUT",
        Op: "load_catalog",
        Cause: errors.New("模拟的底层原因"),
    }
    // 包装会改变最外层动态类型；适配器显式识别错误链。
    err := fmt.Errorf("加载目录: %w", inner)
    logger.LogAttrs(context.Background(), slog.LevelError, "目录加载失败",
        slog.Any("error_detail", errorView{err: err}),
    )
}

把代码保存到独立目录的 main.go 后，读者可以自行运行。按代码定义，error_detail 应当是对象，包含固定 message、允许的 code 和 op；不会包含 Cause 的原始文本。这是预期字段结构，不是本文实际运行得到的输出。日志还有标准的时间、级别、消息字段，时间不应作为字段结构比较的固定值。

适配器结构组包含“包装错误、日志适配器、业务类型”；字段输出组包含“安全消息、错误代码、操作名称”。日志适配器接收包装错误，通过类型识别得到业务类型，并构造安全消息；业务类型提供受限的错误代码和操作名称。这里没有“全部内部字段自动公开”的关系。

示例的白名单是为了展示输出控制，不是通用业务枚举。实际项目应维护自己的稳定分类，并控制自由文本、URL、请求参数和令牌等信息。不能把“错误码可查询”实现为把整个错误对象反射成 JSON，这会把内部细节和日志结构绑定在一起。

errors.As 命中后还检查 target 不为空，是为了处理接口中携带类型化 nil 指针的情况。仅判断 error 接口不为 nil，不能推断底层指针一定非空。陌生类型则只输出安全消息；这是一种明确降级，而不是尝试猜测所有第三方错误的内部字段。

自定义错误类型何时直接实现 LogValue

如果应用拥有某个错误类型，也可以直接为它实现 LogValue，让它返回由已知字段组成的 slog.GroupValue。这样把该类型的值直接交给内置 Handler 时，可以使用它定义的日志表示，减少每个调用点重复拆字段。

但必须注意传入值的动态类型与方法集：方法定义在指针接收者上时，传入结构体值不一定实现 LogValuer；而 fmt.Errorf 使用 %w 包装后，最外层通常已经不是原来的业务类型。包装保留业务错误链，并不意味着外层自动转发内层 LogValue。本文用显式适配器，就是为了在调用点把“要识别错误链”这件事写清楚。

LogValue 应保持轻量、无副作用，不能在里面查询数据库或发网络请求，也不要返回自己形成递归。Logger.With 预绑定属性时，Handler 可能提前处理这些值；不要让动态业务状态依赖不确定的求值时机。

需要统一重写大量既有字段时可以考虑 HandlerOptions.ReplaceAttr，但它拿到的是已解析的属性值，针对非 Group 属性调用，组本身不会触发该回调。它适合有清晰字段约定的集中脱敏或改名，不应当靠一个模糊的 error 键扫描就任意展开整个对象。接入自定义 Handler 时还要确认其 Resolve 和 Group 支持，不能假设它完全等同内置 Handler。

按字段结构安排回归与切换

# 在独立示例目录中运行上面的完整程序，观察 error_detail 类型。
go run main.go

这条命令供读者执行，本文没有运行程序或生成伪造终端截图。回归应比较字段结构，而不是依赖对象键顺序和动态时间：检查 error_detail 为对象、code 与 op 为字符串，以及 Cause 文本没有出现。再分别输入普通未知错误、nil 错误和类型化 nil，确认降级表示符合应用约定。

• 列明哪些旧字段继续保持字符串，哪些新字段使用对象，避免混用同一路径。
• 检查包装后的错误是否通过显式适配器识别，不依赖外层自动继承方法。
• 确保只输出允许的业务字段，不把原始 Error 文本当作天然安全。
• 保留 errors.Is、errors.As 的业务用途，不从日志 JSON 反推错误身份。
• 先更新日志采集字段映射和查询，再逐步切换调用点；需要回退时可停止写入新增对象字段。

slog.Any 换成 slog.String 能展开吗？

不能。String 明确要求一个字符串，会进一步固定为文本表示。它适合经过脱敏的错误描述，不是结构化展开器。

AddSource 为什么没给出 error 的调用栈？

它提供日志语句的位置，不会自动采集错误生成与传播过程的完整堆栈。需要堆栈时，应明确采集来源、输出范围和敏感路径处理规则。

可以直接把 err.Error() 放到 message 里吗？

可以作为展示方案，但要先保证错误文本允许进入日志，避免包含凭据、个人信息或完整请求体。示例故意使用固定安全文本，把稳定分类留给受控字段。

最终需要迁移的不是 Error 方法，而是日志字段约定：普通错误保留其业务身份，适配器定义可公开结构，Handler 负责编码。JSONHandler 的具体处理可参考 https://go.dev/src/log/slog/json_handler.go，对外接口以标准库文档为准。