应使用中间件结合业务语义识别HTTP操作类型并脱敏记录，提取关键标识、避免读取r.Body、统一底层数据库埋点、透传trace_id、分离日志存储、用单调序号替代时间戳排序、预定义最小审计字段集并JSON序列化。
用 log 包 + 中间件记录 HTTP 请求级别的增删改行为
Golang 原生 log 包本身不区分操作类型，得靠你识别请求方法和路径来打标。常见做法是在 HTTP handler 中间件里判断 r.Method 和 r.URL.Path，再拼出可读的操作描述。
比如 POST /api/users → “创建用户”，DELETE /api/users/123 → “删除用户 ID=123”。别只记方法名，要结合业务语义——PATCH /api/orders 可能是“修改订单状态”，不是笼统的“更新”。
- 必须检查
r.URL.Query().Get("id")或chi.URLParam(r, "id")（用 chi 路由时）提取关键标识，否则日志里全是/api/users/{id}这种模板，审计时没法查具体哪条数据 - 避免在中间件里直接调用
log.Printf打印原始r.Body：body 只能读一次，会干扰后续 handler 解析；改用io.TeeReader或提前读取并重置r.Body - 敏感字段（如密码、token）必须脱敏，哪怕只是日志里出现
"password": "***"，也比留空或原样打印强
数据库操作日志不能只依赖 ORM 的钩子
像 GORM 的 BeforeCreate、AfterDelete 看似方便，但它们只在模型层触发，漏掉原生 SQL、事务内多表操作、或绕过 ORM 的直连场景。审计日志要求“所有变更必留痕”，所以得在更底层埋点。
推荐在 database/sql 的 sql.Conn 或自定义 sql.Driver 上做包装，或者用 GORM 的 logger 接口（v2+）配合 Config.SkipHooks: true 关闭默认钩子，自己统一处理。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- GORM 日志默认不包含执行耗时和影响行数，加
Config.Logger = &gormLogger{}自定义实现时，务必从ctx.Value()或stmt.RowsAffected拿到这些值 - 事务内的操作要打上同一
trace_id，否则审计时看不出“这 3 条更新属于同一个下单动作”；可用context.WithValue(r.Context(), "trace_id", uuid.New().String())透传 - 别把日志写进同一个数据库——万一库挂了，操作和日志全丢。至少用本地文件 + 轮转（
lumberjack），或发到独立日志服务（Loki、ELK）
time.Now().UnixMilli() 不足以支撑高并发下的操作排序
多个 goroutine 几乎同时调用 time.Now()，返回的时间戳可能完全一样。审计时看到两条“2024-05-20T10:00:00.000Z 创建用户”却分不清谁先谁后，就失去追溯意义。
解决方案不是换更高精度时钟（Go 的 UnixNano() 也解决不了竞争），而是引入逻辑时钟或序列号。
- 在中间件入口生成单调递增序号：
atomic.AddInt64(&seq, 1)，和时间戳一起写入日志字段"seq": 12345 - 用 Redis 的
INCR做分布式序号（需容忍少量失败，不阻塞主流程），适合多实例部署 - 如果已用消息队列（如 Kafka），直接用 offset 或 timestamp + partition 做全局顺序依据，比本地时间可靠得多
日志字段设计要对齐审计系统的要求
很多团队后期接入 SIEM 或自研审计平台，才发现日志里缺关键字段：没用户 ID、没客户端 IP、没操作结果（成功/失败）、没错误码。临时补字段要改所有埋点位置，成本极高。
一开始就要定好最小必要字段集，例如：user_id、client_ip、operation（字符串，如 "create_user"）、resource_id、status（"success"/"failed"）、error_code（如 "invalid_email"）、timestamp_ms、seq。
-
user_id不能只从 token 解析，要考虑匿名操作（如游客提交反馈），此时填"anonymous"或空字符串，但字段必须存在 -
client_ip别直接取r.RemoteAddr，要按X-Forwarded-For头解析，并校验是否在可信代理列表里，否则容易被伪造 - 所有字段值强制 JSON 序列化（用
json.Marshal），避免日志解析时因引号、换行错乱；别用fmt.Sprintf拼接字符串日志
审计日志不是越详细越好，而是每个字段都得有明确用途。少一个 resource_id，就可能让安全人员花两小时手动翻数据库找对应记录。
