Go 日志脱敏入门：不要把密码、Token 和身份证写进日志

日志是排查问题的基础，但日志也很容易泄露敏感信息。密码、验证码、session ID、访问 token、身份证号、银行卡号、完整手机号，如果进入日志系统，就可能被更多人看到，也很难彻底删除。初学者常见错误是为了调试方便，把整个请求体或结构体直接打印出来。

本文讲 Go 服务里最基本的日志脱敏习惯：少打印、用白名单、敏感字段单独处理，并给关键脱敏逻辑写测试。

不要打印整个请求

危险写法：

log.Printf("login request: %+v", req)

如果 req 包含密码，日志就直接泄露了。更好的方式是只打印必要字段：

log.Printf("login attempt email=%s", req.Email)

即使是邮箱，也要看业务是否允许完整打印。对于公开系统，可以考虑只打印用户 ID 或邮箱 hash。日志的原则是：排查问题需要什么，就打印什么；不需要的不要顺手带上。

用 slog 明确字段

Go 的 log/slog 鼓励结构化字段：

slog.Info("login failed",
	"email", maskEmail(req.Email),
	"reason", "bad_password",
)

脱敏函数：

func maskEmail(email string) string {
	parts := strings.Split(email, "@")
	if len(parts) != 2 || parts[0] == "" {
		return "***"
	}
	name := parts[0]
	if len(name) <= 2 {
		return name[:1] + "***@" + parts[1]
	}
	return name[:2] + "***@" + parts[1]
}

这不是最完美的邮箱脱敏，但表达了思路：日志里不放完整敏感标识。

Token 只打印前后几位也要谨慎

有些人喜欢打印 token 前 6 位帮助排查：

func shortToken(token string) string {
	if len(token) <= 8 {
		return "***"
	}
	return token[:4] + "..." + token[len(token)-4:]
}

这比完整打印好，但仍要谨慎。对于高敏 token，最好完全不打印，只打印请求 ID、用户 ID、操作类型。能不用 token 关联问题，就不要用。

错误包装不要带敏感值

危险：

return fmt.Errorf("login failed password=%s: %w", password, err)

错误最终很可能进入日志。错误信息里不要包含密码、token、验证码。应该写上下文，而不是写秘密：

return fmt.Errorf("login failed for user %d: %w", userID, err)

如果还没有 userID，可以写邮箱 hash 或请求 ID。错误上下文要帮助定位代码路径，不是保存用户输入原文。

外部 API 日志

调用外部接口时，不要打印完整 Authorization：

slog.Info("call payment api",
	"method", req.Method,
	"url", req.URL.Host+req.URL.Path,
)

URL 也要注意。查询参数里可能有 token：

https://example.com/callback?token=secret

记录 URL 时可以只记录 host 和 path，不记录 raw query：

func safeURL(u *url.URL) string {
	return u.Scheme + "://" + u.Host + u.Path
}

日志越靠近边界，越要谨慎。HTTP 请求、数据库错误、第三方响应都可能带敏感内容。

白名单比黑名单稳

黑名单思路是“把 password、token、secret 删掉”。问题是字段名很多，漏一个就泄露。白名单思路是“只允许这些字段进入日志”。比如登录日志只允许：

• request_id
• user_id
• masked_email
• result
• reason

其它字段默认不打印。白名单更啰嗦，但更安全。

测试脱敏函数

func TestMaskEmail(t *testing.T) {
	got := maskEmail("alice@example.com")
	if strings.Contains(got, "alice") {
		t.Fatalf("email was not masked: %s", got)
	}
	if !strings.Contains(got, "@example.com") {
		t.Fatalf("domain missing: %s", got)
	}
}

测试短 token：

func TestShortToken(t *testing.T) {
	if got := shortToken("abc"); got != "***" {
		t.Fatalf("got %q", got)
	}
}

脱敏逻辑看起来小，但属于安全边界。写测试能防止后续重构把完整值又放回日志。

给结构体实现安全输出

有些类型经常出现在日志里，可以给它们提供安全方法，而不是依赖每个调用方记得脱敏：

type LoginRequest struct {
	Email    string
	Password string
}

func (r LoginRequest) LogValue() slog.Value {
	return slog.GroupValue(
		slog.String("email", maskEmail(r.Email)),
		slog.String("password", "***"),
	)
}

使用：

slog.Info("login request", "request", req)

如果你的日志库支持类似接口，就可以把安全输出放在类型附近。即便不用 LogValue，也可以写 SafeFields() 方法返回白名单字段。这样比到处手写脱敏更容易维护。

还要注意第三方错误。有些 SDK 返回的错误里可能包含请求 URL、响应体或认证信息。记录外部错误前，至少要知道它的格式。必要时包装成安全错误，再把原始错误放到受控的调试环境，而不是直接进入普通日志。

日志保留时间也是安全策略

脱敏能减少泄露，但日志仍然可能包含用户行为和业务信息。生产环境应该有明确的日志保留时间和访问权限。开发、测试环境也不要随便使用真实用户数据。安全不是某个函数完成的，而是一整条数据流的约束。

审查新增日志

团队里可以把“新增日志是否包含敏感字段”放进代码审查清单。看到 Printf("%+v", obj)、slog.Any("request", req)、Authorization、password、token 这类内容时，要停下来确认。日志一旦上线，比普通 bug 更难回收。

还可以在测试或静态扫描里查常见字段名。扫描不能替代人工判断，但能拦住明显错误。安全习惯越靠前，后面补救越少。

告警里也不要带敏感值

日志经常会进入告警系统、聊天工具或工单系统。即使应用日志已经限制访问，告警摘要也可能被转发给更多人。所以告警内容同样要使用脱敏字段：

slog.Error("payment failed",
	"user_id", userID,
	"request_id", requestID,
	"reason", safeReason(err),
)

不要把完整请求体塞进告警标题。告警要帮助值班人员定位问题，而不是复制所有现场数据。

小结

Go 日志脱敏的基本原则是少打印、用白名单、敏感字段单独处理。不要打印整个请求体、结构体、Authorization 头、密码、验证码和 token。错误信息也不能带秘密，因为错误最终常会进入日志。

日志是为了排查问题，不是为了保存所有现场。能用请求 ID、用户 ID、操作类型定位的，就不要记录敏感原文。越早养成这个习惯，系统越不容易在日志里埋安全问题。