脱敏必须在日志结构化完成前、进入异步通道前做完，否则导致上下文丢失、字段错漏、性能崩坏；不能在zap.AsyncCore消费goroutine中脱敏，因依赖的Context等已失效且易panic漏脱；应通过MarshalLogObject实现字段级可控脱敏，或对map做浅拷贝+白名单清洗，并提前剥离HTTP Header与Body中的敏感信息。
脱敏必须在日志结构化完成前、进入异步通道前做完，否则上下文丢失、字段错漏、性能崩坏三连击。
为什么不能在 zap.AsyncCore 的消费 goroutine 里做脱敏
常见错误是把 zap.NewAsyncCore 当成“万能异步筐”，把原始结构体或 map 直接塞进去，指望后台协程边写磁盘边脱敏。结果不是 panic 就是漏脱。
-
panic: runtime error: invalid memory address or nil pointer dereference—— 因为脱敏逻辑依赖req.Context()或span.SpanContext()，而这些在后台 goroutine 中早已失效 - HTTP header 里的
Authorization、JSON body 里的access_token、甚至 error.Unwrap() 链中的嵌套敏感值，全被跳过 - 正则编译、JSON 解析等操作拖慢 flush 周期，缓冲区堆积后触发 channel 阻塞，反向卡住业务请求
- 单条脱敏耗时从
0.2ms升至1.8ms，1024条缓冲区 flush 周期从50ms拉长到200ms+
用 MarshalLogObject 实现字段级可控脱敏
这是 zap 场景下最稳的路径：结构体自己决定怎么输出，不靠命名猜测，也不侵入日志调用点。
- 必须用指针接收器：
func (u *User) MarshalLogObject(enc zapcore.ObjectEncoder) error，否则无法处理 nil 字段或嵌套结构 - 只显式添加需暴露字段，敏感字段统一设为
enc.AddString("token", "[REDACTED]")，绝不调用enc.AddReflected - 导出字段（首字母大写）才可被访问；非导出字段自动跳过，无需额外判断
- 避免在该方法中做耗时操作（如 HTTP 请求、数据库查询），否则所有日志路径都会卡住
- 示例中若结构体含
Password string字段，直接写enc.AddString("password", "[REDACTED]")，而非条件判断值是否为空
对 map[string]interface{} 做浅拷贝 + 白名单遍历
当业务层传的是动态 map（比如 HTTP query、JSON body 解析结果），没法改结构体定义，就得靠运行时清洗。
立即学习“go语言免费学习笔记（深入）”；
- 先浅拷贝原 map：
out := make(map[string]interface{})，避免污染原始数据 - 白名单键列表（如
[]string{"user_id", "phone", "id_card", "auth_token"}）比黑名单更安全，也更易维护 - 敏感 key 判定别只看全等，用
strings.Contains(strings.ToLower(k), "token")覆盖X-Auth-Token、access_token等变体 - 替换值统一用固定掩码
"***"，不拼接原始长度（避免泄露位数信息） - 不对 value 做递归解析——除非明确知道它是嵌套 map/slice；否则 JSON 字符串字段（如
body: "{\"token\":\"abc\"}"）会漏脱
HTTP 请求体与 Header 的提前剥离时机
日志中最容易漏的不是结构体字段，而是 request.Body 和 r.Header 里的原始字节流。
- 别在中间件打日志时才读
r.Header.Get("Authorization")——header 是 map，底层仍存原始值；正确做法是 clone 后删掉敏感 key：h := r.Header.Clone(); h.Del("Authorization") - 用
ioutil.ReadAll(r.Body)后必须重置：r.Body = io.NopCloser(bytes.NewReader(bodyBytes))，否则后续 handler 读不到 body - 对 POST /login 的 JSON body，应在
json.Unmarshal后立即脱敏，而不是等日志构造阶段 - URL query 参数（如
?api_key=xxx）要单独提取并清洗，r.URL.Query()返回的是url.Values，需遍历 key 做匹配 - 别信 “我用了中间件，肯定全覆盖”——panic 堆栈里的 args、SQL 日志的 query 参数、gRPC metadata，全在中间件视野之外
真正难的不是写脱敏逻辑，而是把脱敏点嵌进数据生命周期的每个入口：配置加载、HTTP 解析、RPC 反序列化、error 构造……只要有一处没卡住，敏感信息就可能裸奔落地。
