Go slog.Attr 怎么处理敏感字段：组装顺序、日志脱敏与单测核对

接口日志里最容易失控的不是日志级别，而是字段在进入 slog.Logger 前已经被拼好了：手机号、Authorization、订单备注混在一组属性里，处理器再怎么过滤也来不及。slog.Attr 解决的是结构化字段的表达，不会自动替你完成脱敏；比较稳的做法是先在字段组装处划清边界，再把安全字段交给 logger。

slog.Attr 先组什么，决定了脱敏还有没有机会

处理Go标准库的slog.Attr敏感字段，核心逻辑就是调整属性组装顺序，先完成掩码再生成日志属性，搭配统一的白名单过滤和输出校验，就能避免敏感明文外泄。

不管后续日志Handler切换成什么格式，只要原始敏感字符串从来没作为Attr的值传入，就不会出现脱敏规则绕开后明文泄露的问题。

假设请求中带着用户手机号和授权头。下面这种写法看起来简洁，却把原始值直接放进了属性：

attrs := []slog.Attr{
    slog.String("user_phone", phone),
    slog.String("authorization", authorization),
}
logger.Info("request accepted", attrs...)

如果使用的是普通 TextHandler，这些值会照原样输出。slog.Attr 是键值载体，不是安全策略。脱敏应该发生在属性创建之前，或者集中发生在一个自定义 LogValuer 中。

func requestAttrs(phone, authorization string) []slog.Attr {
    return []slog.Attr{
        slog.String("user_phone", maskPhone(phone)),
        slog.String("authorization", maskToken(authorization)),
    }
}

func maskPhone(v string) string {
    if len(v) < 7 {
        return "***"
    }
    return v[:3] + "****" + v[len(v)-4:]
}

这里的关键不是掩码字符用了几个星号，而是原始字符串从未进入日志属性。这样即使后续换成 JSON Handler，也不会因为配置变化把明文重新暴露。

slog.Group 只能整理层级，不能替字段做安全判断

请求日志通常需要把用户、路由和结果分开。slog.Group 很适合表达这种层级，但组里的每个 Attr 仍然要单独判断：

attrs := []slog.Attr{
    slog.Group("request",
        slog.String("method", r.Method),
        slog.String("path", r.URL.Path),
    ),
    slog.Group("user",
        slog.String("id", userID),
        slog.String("phone", maskPhone(phone)),
    ),
}
logger.Info("request finished", attrs...)

不要把整个用户对象通过 fmt.Sprint 变成一个字符串再塞入 slog.String。这会让字段失去结构，也很容易把对象里的 token、邮箱或内部备注一起带出来。组装阶段保留明确的白名单，排查时才能知道每个字段从哪里来。

Logger.With 适合继承哪些字段

logger.With 会生成一个带固定属性的新 logger。请求 ID、服务名、路由这类字段在一次请求内不会变化，放进去可以避免每次调用都重复组装：

reqLogger := logger.With(
    slog.String("request_id", requestID),
    slog.String("route", r.URL.Path),
)
reqLogger.Info("start")
reqLogger.Info("database query finished", slog.Int64("rows", rows))

但不要把临时访问令牌、完整查询参数或请求体放进 With。它们会跟着 logger 继续传播，后面某个与鉴权无关的日志点也可能把属性写出来。一个简单判断是：字段是否能安全地伴随本次请求的所有日志？不能，就留在具体事件的白名单里。

用 slog.NewTextHandler 把脱敏结果测出来

脱敏测试不要只测 maskPhone 返回了什么；日志处理器的输出才是最终边界。可以用 bytes.Buffer 接住文本日志，再同时检查安全字段和禁用字段：

func TestRequestAttrsRedactSecrets(t *testing.T) {
    var buf bytes.Buffer
    handler := slog.NewTextHandler(&buf, nil)
    logger := slog.New(handler)

    logger.Info("request", requestAttrs("13800138000", "Bearer abc123")...)
    got := buf.String()
    if !strings.Contains(got, "138****8000") {
        t.Fatalf("masked phone missing: %s", got)
    }
    if strings.Contains(got, "13800138000") || strings.Contains(got, "abc123") {
        t.Fatalf("secret leaked: %s", got)
    }
}

再补一个结构测试，确认 user.phone 没有因为改成 slog.Group 而变成不可控的整段字符串。生产环境还应把 JSON Handler 跑一遍，因为不同 Handler 的呈现形式不同，但它们都不应该重新得到原始敏感值。

常见问题：slog.Attr 脱敏时最容易漏掉什么

只在错误日志里脱敏，正常日志可以不处理吗？

不建议。正常请求日志通常保留时间更久、查询更频繁，字段白名单和掩码规则应在公共组装函数里统一执行。

能不能在 Handler 里统一删除 authorization？

可以作为最后一道防线，但不能替代上游白名单。自定义 Handler 还要覆盖嵌套 Group、重复键和 LogValuer 展开的情况，维护成本更高。

手机号长度不符合预期时应该怎么记？

宁可返回固定的 ***，也不要原样输出“方便排查”。异常输入往往正是最需要保护的输入。

发布前的最小核对清单

• 搜索日志字段名，确认 authorization、cookie、token 不在默认白名单。
• 用原始手机号、短手机号和空令牌各跑一次测试。
• 分别使用 TextHandler 与 JSONHandler 检查最终输出。
• 检查 Logger.With 的继承属性，确认不会传播临时秘密。