Iris框架不内置用户行为埋点能力，需手动集成中间件或日志系统；通过Use钩子记录请求基础行为，Handler中埋具体业务动作，并注意异步上报、字段规范与数据团队对齐。
Iris 框架本身不内置用户行为埋点能力，必须手动集成或借助中间件+日志/监控系统实现。它只提供 HTTP 请求生命周期钩子（如 Use、Done、OnErrorCode），埋点逻辑得你写进去。
用 Use + Context 记录基础请求行为
Iris 的中间件是埋点第一入口，适合记录页面访问、API 调用等粗粒度事件。关键点在于：不能只依赖 Request.URL，要结合 ctx.GetCurrentRoute().Name() 或自定义路由标签区分语义；同时注意 ctx.Values().Set() 只在当前请求生命周期有效，别误当成全局状态用。
- 在
Use中调用ctx.RecordLog()或发 HTTP 请求到埋点服务（如 Kafka Producer 封装、HTTP 上报 endpoint） - 提取用户标识优先级：Header
X-User-ID→ Cookieuser_sid→ JWT payloadsub字段（需提前解析） - 避免在中间件里做耗时操作（如直连 MySQL 写日志），否则拖慢所有请求；异步上报更安全
- 示例片段：
app.Use(func(ctx iris.Context) { start := time.Now() ctx.Next() duration := time.Since(start).Milliseconds() event := map[string]interface{}{ "event": "http_request", "path": ctx.Request().URL.Path, "method": ctx.Request().Method, "status": ctx.GetStatusCode(), "duration_ms": duration, "user_id": ctx.GetHeader("X-User-ID"), "timestamp": time.Now().UnixMilli(), } // 异步投递到日志队列或上报服务 sendToBeacon(event) })
在 Handler 里埋具体业务动作（如按钮点击、表单提交）
路由 handler 才是细粒度埋点的核心位置——比如“用户点击了首页 Banner”“提交了注册表单但失败”。这里容易犯的错是把埋点逻辑和业务逻辑耦合太紧，导致后续难维护或漏埋。
- 每个需要埋点的业务动作，应封装为独立函数（如
trackClickBanner(ctx, bannerID string)），统一处理上下文、用户 ID、设备信息等字段 - 不要在 handler 里直接拼 JSON 发 HTTP；用结构体 + 序列化，便于后期加字段、做校验
- 注意错误路径也要埋点：比如表单验证失败时，埋
event: "form_submit_failed"并带上reason: "email_invalid" - 如果用了 JWT，建议在 middleware 解析一次并存入
ctx.Values().Set("claims", claims)，handler 里直接取，避免重复解析
避免踩 ctx.Next() 和并发写日志的坑
很多人在 Use 里调用 ctx.Next() 后立刻读响应状态，结果拿到的是 0（未写入）；或者多个 goroutine 并发写同一个日志 buffer 导致 panic。
-
ctx.GetStatusCode()必须在ctx.Next()之后调用，且仅在同步 handler 场景下可靠；异步写响应（如流式返回、defer 写）时该值不可信 - 日志上报务必用 channel + 单独 goroutine 消费，或用现成库如
zerolog+sync.Pool处理 buffer - 别在
Done钩子里做重试逻辑——它不保证执行顺序，可能重复触发 - 测试时用
httptest.NewRecorder()捕获响应，再检查埋点是否触发，比打日志更可靠
真正难的不是怎么写几行埋点代码，而是字段规范能否对齐数据团队的要求：比如 where 字段到底填页面 URL 还是前端传的 page_name，what 是用动词短语还是固定枚举。这些得和下游数仓 schema 对齐，否则埋了也白埋。
