日志脱敏必须在结构化日志输出前完成，依赖字段名与值类型精准识别敏感数据；log.Printf等纯文本输出无法区分字段边界，易误脱或漏脱；zap等结构化日志框架支持字段级动态白名单脱敏，采集器仅负责转发不参与脱敏。

日志脱敏必须在结构化日志输出前完成，集中式采集只负责转发，不处理内容；脱敏逻辑不能依赖采集器或后端系统，否则敏感字段早已泄露。

为什么log.Printf和fmt.Println不能用于脱敏场景

它们输出纯文本，字段边界模糊，无法精准识别和替换敏感值（如手机号、身份证、token）。即使正则匹配也极易误伤或漏脱，且无法区分上下文——比如user_id字段在登录成功日志里要脱敏，在内部调试日志里可能不需要。

• 脱敏必须基于字段名+值类型判断，只有结构化日志（如zap、zerolog）才能拿到明确的key和value
• log.Printf("user: %s, token: %s", u.Name, u.Token) 这类拼接日志，token已混入字符串，采集器无法还原原始字段
• 容器 stdout 日志一旦写出，就不可逆；脱敏必须发生在logger.Info()调用之前

在zap中实现字段级动态脱敏

不要全局过滤所有token或password字段——实际业务中这些键名可能叫access_token、auth_key、secret，甚至嵌套在user.credentials里。需结合字段路径与值特征做判断。

• 使用zap.WrapCore封装自定义zapcore.Core，在WriteEntry阶段遍历所有Field，对匹配键名的字符串值做掩码（如****-abcd）
• 推荐白名单机制：只对明确列出的字段脱敏，例如[]string{"token", "password", "id_card", "phone"}，避免误杀
• 对数值型、布尔型字段跳过脱敏，防止把status: 401错改成status: ****
• 示例脱敏逻辑：

  func maskIfSensitive(key string, val interface{}) interface{} {
  	if !isSensitiveKey(key) {
  		return val
  	}
  	if s, ok := val.(string); ok && len(s) > 4 {
  		return s[:2] + "****" + s[len(s)-2:]
  	}
  	return val
  }

Fluent Bit/Promtail采集时不做脱敏，只做标签增强

采集器不是脱敏环节，它的作用是可靠转发+打标。任何试图在filter阶段用正则替换日志内容的做法都不可靠——JSON结构可能换行、引号转义、字段顺序不定，正则极易失效。

Golang Samber Hot

在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。

下载

立即学习“go语言免费学习笔记（深入）”；

• 确保采集器配置中Parser启用json解析，而非regex，让Loki/ES直接按字段索引
• 在[FILTER]中只添加静态标签，如service、env、pod_name，不修改日志体
• 若必须拦截含敏感字段的日志（如含"error": "invalid token: abc123"），应在应用层用logger.Debug降级，而非靠采集器过滤——因为debug日志本就不该进生产采集流

跨服务透传时trace_id不能脱敏，但下游字段要重新校验

trace_id是链路追踪的唯一标识，必须原样透传；但下游服务收到请求后，其自身生成的日志字段（如user_id、order_no）仍需独立脱敏，不能假设上游已处理。

• HTTP中间件中从X-Trace-ID读取并写入context，但logger.With(zap.String("trace_id", tid))不参与脱敏逻辑
• 下游服务的handler里，即使user_id来自上游header，也要再次走脱敏检查——因为字段来源不可信
• gRPC场景下，metadata.MD中的authorization字段必须在server interceptor里剥离或掩码，不能等日志打印时才处理

真正容易被忽略的是：脱敏规则必须随业务演进持续更新。新接口加了bank_account字段？没加到白名单里，它就裸奔进Loki了。脱敏不是一次配置，而是和API Schema变更同步的代码逻辑。