Go log/slog HandlerOptions 怎样控制源文件信息

给 slog.NewJSONHandler 或 slog.NewTextHandler 传入 HandlerOptions{AddSource: true}，即可输出日志语句的源码位置。需要改写路径时，用同一个选项对象的 ReplaceAttr 处理 slog.SourceKey 对应的 *slog.Source；需要关闭时，在构造Handler时将AddSource设为false。

官方地址：https://go.dev/

面对一条“报告已保存”的日志，我通常先问：缺少的是业务标识，还是写出日志的代码位置？本文用 report_id 保留业务关联，再决定是否加source。它们回答不同问题。以下采用标准库的公开能力说明配置取舍，不把源码字段描述成新近流行的趋势，也不虚构性能测量。

先判断是否需要记录调用位置

源码位置帮助维护者找到产生日志的语句，适合代码路径较多、相似消息较多的场景；业务字段帮助定位某份报告或请求。若日志只用于统计报告数量，文件名与行号未必需要进入每条记录。

在结构化日志中，建议把位置作为独立属性交给Handler，而不是手写进msg。这样下游可以单独显示或隐藏source，消息文本也不会因行号变化而变成不同内容。

给真正使用的Handler开启AddSource

选项属于Handler。程序若创建了一个带AddSource的Handler，却继续调用另一个Logger，就不会获得预期字段。本文直接使用返回的logger，避免默认Logger与局部Logger混用。

将下面完整程序保存为main.go。第一条日志使用开启源码位置的Handler，第二条使用关闭源码位置的独立Handler：

package main

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

// newLogger 在创建内置Handler时一次性确定源码字段策略。
func newLogger(addSource bool) *slog.Logger {
    opts := &slog.HandlerOptions{
        AddSource: addSource,
        ReplaceAttr: func(groups []string, a slog.Attr) slog.Attr {
            // 同时判断key与实际类型，避免把业务字符串source当作源码对象。
            if a.Key == slog.SourceKey {
                if src, ok := a.Value.Any().(*slog.Source); ok && src != nil {
                    copySource := *src // 复制后修改，保持回调的局部变换清楚可读。
                    copySource.File = filepath.Base(copySource.File)
                    return slog.Any(a.Key, ©Source)
                }
            }
            return a
        },
    }
    return slog.New(slog.NewJSONHandler(os.Stdout, opts))
}

func main() {
    logger := newLogger(true)
    logger.Info("report stored", "report_id", "demo-42")
    // 关闭源码字段使用另一个Handler，不修改已使用的options指针。
    quiet := newLogger(false)
    quiet.Info("report stored", "report_id", "demo-43")
}

运行方式：

# 使用包含log/slog的Go工具链运行独立示例。
go run main.go

预期第一条JSON记录含source，第二条不含内置source；实际时间、函数名和行号取决于文件与构建环境。此处只描述源码预期，没有将日志输出作为本机实测展示。

用ReplaceAttr缩短文件路径

官方内置源码属性以SourceKey为键，其值是Source指针。示例先判断键，再做类型断言，复制结构体后只修改File。Function和Line保留原有值，便于继续定位。filepath.Base缩短的是路径显示形式，并不能保证两个不同源码文件拥有不同的短名。

不建议业务代码也使用source作为普通字段名；类型判断虽然能避免误改字符串，日志消费者仍可能面对重复键。给业务来源命名为report_origin等更具体的属性，通常更容易解释。

ReplaceAttr是属性处理点，不是对最终整行JSON做字符串替换。不要把已经序列化的source重新按冒号拆分：文件路径和输出格式各有细节，应优先处理Source结构化字段。

在定位能力与日志成本之间取舍

只保留文件短名能减少目录信息，但也会削弱定位能力。如果两个目录都有handler.go，短名加行号仍可能不够。可以在应用日志中保留明确的组件属性，并结合部署版本定位代码；这属于应用约定，不是AddSource自动补充的内容。

如果完全不需要source，直接关闭AddSource更明确。以下片段演示已经统一开启后，在属性策略中删除该字段的写法；它适合作为现有ReplaceAttr规则的一部分，而不是节省源码计算的办法：

// source策略应在构造Handler时选择，而不是在每个业务调用处拼路径。
opts := &slog.HandlerOptions{
    AddSource: true,
    ReplaceAttr: func(groups []string, a slog.Attr) slog.Attr {
        if a.Key == slog.SourceKey {
            if _, ok := a.Value.Any().(*slog.Source); ok {
                return slog.Attr{} // 返回零Attr，丢弃源码属性。
            }
        }
        return a
    },
}
logger := slog.New(slog.NewTextHandler(os.Stdout, opts))
logger.Info("report stored") // 此处不再输出内置source。

对已有Logger，别依赖修改最初传入的opts指针来动态切换。需要另一种策略时，构造新的Handler和Logger，并在应用中按约定替换依赖。这样各输出端到底采用哪种策略更容易追踪。

性能方面不预设具体百分比。若业务日志量大，应在自己的消息体、属性数量和输出目标上比较开启前后的耗时、分配与记录大小；示例未提供任何基准结果。

按输出字段决定是否采用

实际采用时，先选一条已知调用点的日志，比较source是否存在、File是否按约定缩短、Line是否能对应当前部署的源码，再决定推广范围。不要把File是否包含绝对路径单独当作可靠定位的全部条件。

如果项目有统一封装的日志函数，source可能指向封装层调用日志的语句。AddSource并不会自动理解哪个栈帧是业务期望的入口；封装层需要另行设计调用位置传递，本文保持直接调用Logger的边界。

开了AddSource为什么Debug没有输出？

位置配置与日志级别是不同条件。先确认Handler允许相应级别；AddSource不会让原本被过滤的消息重新出现。

TextHandler能用同样的选项吗？

可以使用HandlerOptions，但文本与JSON的显示形状不同，不能依赖逐字相同的source字符串。

自定义Handler会自动遵循HandlerOptions吗？

HandlerOptions用于内置Handler构造函数。自定义实现要自行定义并兑现配置行为，不能仅靠实例化这个结构体改变任意Handler。

我会先保留report_id这样的业务标识，再根据排障需要开启source。要缩短路径，就在ReplaceAttr中处理Source.File；要完全关闭，就在构造Handler时关闭AddSource。把定位与业务信息各自写清楚，输出策略才容易维护。

资料：HandlerOptions文档；Go官方结构化日志介绍。