应在请求入口用 context.WithValue 注入审计元数据，跨服务通过 header/metadata 透传，记录 trace_id、resource_id、before/after 快照等可追溯字段，异步缓冲写入防延迟。
如何在 Go 微服务中注入统一审计上下文
审计日志不是事后补的装饰，而是请求一进入就要绑定身份、操作意图和链路标识。Go 里最可靠的方式是利用 context.Context 携带审计元数据，而非依赖全局变量或中间件局部变量——后者在 goroutine 泄漏或异步调用时极易丢失。
常见错误是只在 HTTP handler 里解析 X-User-ID 或 JWT，然后存在局部 struct 里传参；一旦进 go func() 或调用下游 gRPC，信息就断了。
- 必须在入口（如 Gin 的
gin.Context或标准http.Request）解析认证信息后，立即用context.WithValue()注入audit.UserKey、audit.ActionKey等自定义 key - key 类型必须是 unexported struct（比如
type userKey struct{}），避免与其他模块冲突 - 下游服务调用（gRPC / HTTP client）时，需显式将当前 context 传入，例如
client.Do(ctx, req)，而不是用context.Background() - 不要在 context 中塞完整用户对象，只存必要字段（如
user_id、role），避免内存泄漏和序列化问题
审计日志该记录什么字段才真正可追溯
“操作成功”“修改了用户”这类模糊日志在排查时毫无价值。真正能定位问题的字段必须满足：可反查请求、可还原操作意图、可关联上下游。
典型缺失字段包括：trace_id（非仅 span_id）、resource_id（被操作实体 ID，不是 URL 路径）、before/after 快照（至少关键字段）、source_ip（注意代理透传）、user_agent（区分 App/iOS/PC）。
立即学习“go语言免费学习笔记（深入）”；
-
operation字段应为动宾短语（如"update_order_status"），而非方法名（"UpdateOrder"）或 HTTP 方法（"PUT"） - 敏感字段（如密码、token）必须脱敏，且脱敏逻辑要统一（推荐用
strings.Repeat("*", len(s))而非固定替换） - 避免记录整个 request body，优先提取业务关键字段（如订单金额、状态变更值），否则日志体积爆炸且检索困难
- 若使用结构化日志（如 zap），用
logger.With(...).Info("audit")，别拼接字符串
跨服务调用时审计链路怎么不中断
单体应用里 context 一路透传没问题，但微服务间 HTTP/gRPC 调用默认不传递 context 中的 value。靠 header 手动搬运是唯一可行路径，且必须约定协议。
现象：A 服务记录了 trace_id 和 user_id，B 服务日志里 trace_id 存在但 user_id 为空——说明 header 透传漏了字段。
- HTTP 调用：所有 outbound 请求必须显式设置
req.Header.Set("X-Trace-ID", traceID)、req.Header.Set("X-User-ID", userID)，不能依赖中间件自动携带 - gRPC 调用：用
grpc.Metadata附加，且服务端需在 interceptor 中从 metadata 提取并写回 context，示例：md, _ := metadata.FromIncomingContext(ctx) - 关键陷阱：Nginx 或 API 网关可能默认 strip 掉带下划线的 header（如
X_User_ID），务必改用中划线命名（X-User-ID）并确认网关配置允许透传 - 不要复用 OpenTracing 的
span.Context()做审计字段载体——它不包含业务身份信息，且生命周期与 trace 绑定，易误删
审计数据落地时性能与一致性的平衡点
把审计日志同步写入 MySQL 或 Elasticsearch 看似稳妥，实际会让接口 P99 延迟飙升 200ms+，尤其在高并发场景下。异步写入又怕丢日志。
真正可用的方案是：内存缓冲 + 本地文件暂存 + 后台批处理上传，而非简单加个 goroutine 丢给 channel。
- 用 ring buffer（如
github.com/cespare/xxhash配合sync.Pool）缓存最近 1000 条审计事件，满则阻塞写入（防 OOM） - 每 5 秒或每 100 条 flush 到本地 JSON Lines 文件（
/var/log/audit/service-a-20240512.log），文件按天轮转 - 独立守护进程（非主服务 goroutine）扫描本地文件，上传至中心存储；上传成功后标记归档，失败则重试三次后告警
- 禁止在审计写入路径中调用任何外部 RPC 或 DB 查询——审计本身不能成为系统瓶颈或故障放大器
最常被忽略的是审计字段的时序一致性：created_at 必须用服务端 time.Now().UTC()，而非前端传入的时间戳；duration_ms 应在 handler defer 中计算，而非 middleware 里粗略估算。
