直接用net/http+sync.map可实现最小闭环埋点，关键在于防丢、防卡、防崩：需限请求体长度、延迟解析json、统一毫秒时间戳；sync.map适用于分钟级内存统计，超10万key或需持久化时应换sqlite/redis；审计与埋点日志必须物理隔离且异步落盘；opentelemetry埋点须带业务属性并透传trace id。
直接用 net/http + sync.Map 就能跑通最小闭环，不需要 SDK、Kafka 或中间件。关键不是“怎么埋”，而是“埋完数据不丢、不卡、不崩服务”。
HTTP handler 里怎么收行为日志而不被大 body 拖垮
用户发个 10MB 的 JSON 到 /track，不加限制会吃光连接池和内存。
- 用
io.CopyN(ioutil.Discard, r.Body, 1024)或http.MaxBytesReader限长，比如只读前 1KB —— 行为字段通常很短，超长基本是恶意或误配 - 结构体定义用
json.RawMessage延迟解析Props字段，避免每次 decode 都全量反序列化 - 时间戳统一用
time.Now().UnixMilli()，毫秒级序确保聚合时不会乱序
短期 UV/PV 统计用 sync.Map 但得知道它撑不住什么
sync.Map 适合分钟级、内存态、低持久性统计，比如看当前 5 分钟内各页面 UV。但它不是数据库，别指望它扛住百万 key 或长期运行不 GC。
- key 设计建议用
"page:/home|20260701"这类带时间分区的字符串，避免单 key 膨胀 - 不要在
sync.Map.LoadOrStore里做复杂计算（如 JSON marshal），否则锁竞争加剧 - 超过 10 万活跃 key 或需跨进程共享时，必须换 SQLite（WAL 模式 + 批量事务）或 Redis
审计日志和埋点日志不能混写，且必须异步落盘
审计要求“操作必留痕”，埋点允许少量丢失；但两者若共用一个 log.Printf 或同一个文件句柄，轻则字段错乱，重则阻塞主流程。
- 审计结构体强制含三要素：
Action（如"user_update_email"）、ResourceID（如"u_789"）、IP（从context提取，不信任 header） - 用带缓冲的
chan *AuditEvent（容量 1000）接收事件，单独 goroutine 每 10 条或 500ms flush 一次 - 消费失败时写入本地临时文件（如
/var/log/app/audit_pending.log），启动时先回放 —— 这比丢日志强十倍
OpenTelemetry 埋点别只打 Span，要带业务属性
只调 tracer.Start(ctx, "handleTrack") 然后 span.End()，出来的 trace 里只有耗时，查问题时还是得翻代码猜逻辑。
- 在 span 上显式设属性：
span.SetAttributes(attribute.String("event", "page_view"), attribute.String("uid", uid)) - 敏感操作（如删账号）额外打 event：
span.AddEvent("user_deleted", trace.WithAttributes(attribute.String("reason", "fraud"))) - 别让 trace ID 只活在 HTTP 层 —— gRPC 调用、DB 查询、消息发送都得透传
ctx，否则链路断在第一个跳转
真正难的不是把 uid 和 event 写进日志，而是确保每次请求的 trace ID 全链路不变、每次审计的 userID 来源可信、每次限流的 resourceName 格式统一。这些细节不抠，埋点越全，排查越乱。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
