Go slog.HandlerOptions.AddSource 为什么会影响日志定位：调用点、性能与安全边界

线上日志里只看到“请求失败”，却找不到是哪一行打出来的，这时可以给 Go 的 log/slog handler 打开 AddSource。它会把日志调用点写进 source 字段；代价是每条被处理的记录都要计算源文件和行号，而且包装 logger 时还要留意调用层是否被正确跳过。

AddSource 到底改变了哪一条日志数据

HandlerOptions 同时服务于 slog.NewTextHandler 和 slog.NewJSONHandler。设置 AddSource 后，handler 会计算日志记录的源代码位置，并增加名为 source 的内置属性。文本 handler 通常把它写成 FILE:LINE，JSON handler 则输出包含文件、函数和行号的对象。

先用最小程序观察结果：

package main

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

func main() {
    handler := slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{
        AddSource: true,
    })
    logger := slog.New(handler)
    logger.Info("读取配置", "file", "app.yaml")
}

运行后重点看 source=main.go:14 一类字段。它不是从消息文本里猜出来的，而是 handler 根据记录保存的程序计数器回溯得到的。日志内容不变，增加的是可定位证据。

为什么包装函数会让 source 指向错误位置

问题通常出在项目自己的日志门面。直接调用 logger.Info 时，记录里的程序计数器来自业务调用点；如果先进入 InfoWithRequest，再由包装函数调用 logger，默认 handler 可能只能看到包装函数那一层。

func InfoWithRequest(logger *slog.Logger, requestID, msg string) {
    logger.Info(msg, "request_id", requestID)
}

func handle(logger *slog.Logger) {
    InfoWithRequest(logger, "req-42", "保存订单")
}

这个结果不代表 AddSource 失效，而是 source 的语义仍然是“记录创建时看到的调用点”。如果团队必须让包装后的日志指向业务层，应在包装层使用 logger.With 统一字段，或者在设计门面时明确调用层级和可测试性；不要只在输出端猜测并改行号。

性能和安全边界要分开判断

源位置计算与日志级别判断不是一回事。handler 会先判断记录是否需要处理；只有真正进入处理路径的记录，才会追加 source。即便如此，高频的 Info 日志仍然可能带来调用栈定位和格式化成本。生产切换前，建议用真实日志量做一次基准：关闭和开启 AddSource 各跑同一批请求，比较吞吐、延迟和输出体积。

安全上，source 不是脱敏机制。默认输出可能包含服务器目录结构，日志收集平台还可能把完整路径暴露给更多读者。可以用 ReplaceAttr 只保留文件名：

replace := func(groups []string, attr slog.Attr) slog.Attr {
    if attr.Key == slog.SourceKey {
        source := attr.Value.Any().(*slog.Source)
        source.File = filepath.Base(source.File)
    }
    return attr
}

handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
    AddSource:   true,
    ReplaceAttr: replace,
})

这里需要注意两点：一是只处理顶层内置的 source 字段，二是不要把用户输入拼进文件名或函数名再写入日志。业务字段仍要按账号、令牌、Cookie 和个人信息单独做过滤。

用四个检查点决定是否开启

• 定位需求：故障排查是否真的需要精确到文件和行号，还是 request_id、函数名和 trace_id 已经足够。
• 日志频率：把源位置优先放在告警、错误和关键状态变更上，低级别高频日志先做压测。
• 包装层：为日志门面写一个断言，确认 source 指向预期层级，而不是只检查字段存在。
• 输出范围：检查生产日志是否泄露绝对路径，并通过 ReplaceAttr 做最小化处理。

常见问题：AddSource 的几个误解

AddSource 会自动定位到最外层业务函数吗？

不会。它记录的是当前日志记录对应的程序计数器；包装函数如何创建记录，会直接影响 source 位置。

只要关闭 AddSource，日志就没有性能成本了吗？

不会。级别判断、属性解析和输出仍有成本；关闭的只是源位置计算与字段输出。

ReplaceAttr 能不能把 source 改成任意业务名称？

可以重写或删除输出属性，但不建议伪造调用位置。更稳妥的做法是保留真实 source，同时增加明确的业务组件字段。

把结论落到发布前检查

AddSource 适合拿来增强故障证据，不适合当作默认的日志安全方案。打开它之后，至少验证一次直接调用和包装调用的 source，再检查绝对路径、敏感业务字段与高频日志成本。这样得到的 source 才是可用的定位信息，而不是一条看似完整却会误导排障的装饰字段。