Go slog.HandlerOptions.AddSource 有什么代价：调用点定位、日志字段与生产开关

线上日志里只看到“处理失败”，却找不到是哪一层发出的，这种排查很容易在一堆同名函数之间来回翻。Go 的 log/slog 可以通过 HandlerOptions.AddSource 把调用文件、行号和函数名写入 source 字段，定位速度会明显提升；代价是每条被处理的日志都要做调用点定位，并增加输出体积。

先看 source 字段解决了哪一种问题

slog 的日志记录本身包含时间、级别、消息和属性。打开 AddSource 后，handler 会再把产生日志的源码位置写入记录。一个简化的 JSON 输出大致如下：

setup := slog.HandlerOptions{
    Level:     slog.LevelInfo,
    AddSource: true,
}
logger := slog.New(slog.NewJSONHandler(os.Stdout, &setup))
logger.Info("cache refresh failed", "key", "user:42")

输出里的 source 通常包含 function、file 和 line。当多个包都输出“refresh failed”时，调用点比单独的消息文本更有辨识度。

调用点定位为什么会产生额外成本

没有 AddSource 时，handler 主要处理已经构造好的日志记录。打开后，它还要从记录中的调用深度定位源码位置，再把位置转换为可输出的字段。成本不只是一项：有调用点查找、路径和函数名整理，以及 JSON 文本变长带来的写出压力。

这不等于“打开后每条日志都会变慢到不可用”。真正的影响取决于日志量、handler 类型、输出目标和日志级别。一个每秒几十条的后台任务，通常更看重定位收益；一个每秒几十万条的访问日志管道，就应该先测再决定。

用最小基准把开关差异测出来

先固定消息和属性，只改变 AddSource，避免把日志格式、终端输出和业务计算一起算进去。下面的测试放在同一个包中运行：

func BenchmarkSlogSource(b *testing.B) {
    for _, addSource := range []bool{false, true} {
        b.Run(fmt.Sprintf("source-%t", addSource), func(b *testing.B) {
            var dst bytes.Buffer
            options := &slog.HandlerOptions{AddSource: addSource}
            logger := slog.New(slog.NewJSONHandler(&dst, options))
            b.ResetTimer()
            for i := 0; i 

使用 go test -run '^$' -bench BenchmarkSlogSource -benchmem 运行。重点看两组的 ns/op、B/op 和 allocs/op，不要只盯着单次耗时。输出目标最好使用内存缓冲区；如果直接写终端或文件，I/O 抖动会盖住开关差异。

生产环境怎样设置才不影响主要日志链路

一个实用的做法是把开关放到日志初始化层，而不是散落在业务调用处：

func newLogger(env string, out io.Writer) *slog.Logger {
    addSource := env != "prod"
    options := &slog.HandlerOptions{
        Level:     slog.LevelInfo,
        AddSource: addSource,
    }
    return slog.New(slog.NewJSONHandler(out, options))
}

开发和预发布打开，便于核对日志来源；生产默认关闭并不意味着永远不能打开。遇到只靠消息无法定位的故障，可以临时提高相关组件的日志级别或在短时间灰度开启，再用明确的截止时间回收配置。

如果线上必须保留 source，至少要先确认三件事：日志吞吐上限是否已用真实流量压测，日志采集端是否限制单条大小，文件路径是否会泄露构建目录或内部用户名。调用点字段对排障有帮助，但也可能扩大敏感路径暴露面。

上线前的检查与回退

1. 用固定基准比较两组 ns/op、B/op、allocs/op，保存 Go 版本和机器信息。
2. 在预发布检查 JSON 日志是否真的出现 source.file、source.line 和 source.function。
3. 在采集端确认 source 字段不会触发单条日志截断、字段冲突或敏感路径告警。
4. 把生产开关和回退值写进配置说明；发现 CPU、分配或日志体积异常时，先关闭 AddSource，再分析样本。

这里别急着用一次本地基准给线上下结论。日志输出格式、调用深度和采集链路都会改变结果，开关最终应由真实流量下的观测数据决定。

常见问题

AddSource 会改变日志级别吗？

不会。它只控制调用点信息是否加入 handler 的输出；日志级别仍由 HandlerOptions.Level 和调用方法共同决定。

为什么打开了 AddSource 却看不到 source？

先确认使用的是支持该选项的 handler，并检查采集端是否丢弃嵌套字段。也要确认实际运行的初始化路径就是修改过的那一处。

source 里的文件路径能不能只保留文件名？

可以在日志采集或输出格式层做脱敏、裁剪，但不要直接修改标准库记录来掩盖问题。先确认团队仍能凭文件名和行号定位到源码。

低频错误日志是否值得打开？

通常值得。低频错误的定位收益往往高于额外成本，但仍应检查路径泄露和单条日志长度，并在预发布验证实际输出。

小结

HandlerOptions.AddSource 是一个很直接的排障开关：它把日志消息和调用位置放在同一条记录里。它的代价来自调用点定位、字段格式化和更大的输出，而不是某个固定百分比。用同一基准测清楚，再按环境和日志价值分层设置，通常能在定位效率与吞吐之间取得更稳妥的平衡。