用户生命周期行为埋点不应全量塞入全局中间件，而需分层注入：登录/登出在AuthMiddleware中触发，页面访问用路由级中间件，关键操作（如注册完成、支付成功）必须在Handler内显式调用埋点函数。
直接说结论：用户生命周期行为埋点不该塞进中间件里做全量拦截，而应按阶段拆解、分层注入——登录/登出用 AuthMiddleware 埋点，页面访问用路由级中间件，关键操作（如注册完成、支付成功）必须在 Handler 内显式调用埋点函数。
为什么不能把所有埋点逻辑都写进全局中间件？
全局中间件（比如 r.Use(TrackMiddleware)）对每个请求都执行一次，但用户生命周期事件不是“每个请求都发生”的：登录只发生在 /login，登出只在 /logout，首次注册只触发一次。强行在全局中间件里判断路径、匹配动作，会导致：
- 大量无意义的条件判断和字符串匹配，拖慢所有接口（包括健康检查、静态资源等）
-
c.Request.URL.Path可能被反向代理重写或带 query 参数，靠路径硬匹配极易漏埋或误埋 - 无法获取业务上下文中的关键字段（如新注册用户的
user_id、邀请码来源），因为 Handler 还没执行 - 埋点上报失败时，
c.Abort()会直接中断整个请求链，连 401 都返回不了
登录/登出这类身份变更事件，该在哪埋？
必须放在鉴权中间件内部，且仅在状态真正变更时触发。例如 AuthMiddleware 在验证通过后，检查 c.Get("user_id") 是否为新值，再调用埋点函数：
- 登录成功后，
c.Set("user_id", uid)和c.Set("login_time", time.Now())要同步写入上下文 - 登出接口的 Handler 中，先调用
clearSession(c)，再显式执行trackEvent(c, "user_logout", map[string]interface{}{"uid": c.MustGet("user_id")}) - 避免在中间件里调用异步上报（如 goroutine + HTTP client），防止上下文
c在 Handler 返回后已被回收，导致c.MustGetpanic
页面访问、停留时长这类行为，怎么避免重复埋点？
用路由组中间件 + 请求 ID 去重，而不是每个请求都发一次：
- 给前端返回的 HTML 或 JSON 中注入唯一
X-Request-ID响应头，由 Gin 的gin.LoggerWithConfig自动生成 - 中间件中用
c.GetHeader("X-Request-ID")作为埋点事件的session_id字段，服务端聚合时可识别同一用户连续点击 - 对 SPA 应用（Vue3/React），前端路由跳转不触发后端请求，所以后端只埋“首屏加载”和“API 接口调用”，页面内跳转由前端 SDK 上报
- 停留时长不能靠后端计算——后端只知道请求开始和结束时间，不知道用户是否切走了窗口。这类指标必须由前端监听页面 visibilityState 变化后主动回调
/api/track/stay
埋点数据结构和上报时机，哪些细节容易翻车？
最常被忽略的是上下文生命周期和错误兜底：
- 所有埋点函数必须接收
*gin.Context，但只读取c.MustGet和c.GetHeader，禁止调用c.JSON或c.Abort，否则会污染主流程 - 上报用 HTTP client 时，务必设超时（
context.WithTimeout(ctx, 500*time.Millisecond)），并忽略错误（go func(){ ... }()不要等结果） - 敏感字段（如手机号、身份证号）必须在埋点函数内部脱敏，不能依赖前端传来的已脱敏值——攻击者可伪造请求头绕过前端逻辑
- 如果用了 Redis 缓存用户行为序列，注意
c.Next()后 Handler 可能 panic，需在 defer 中补全埋点（如“异常退出”事件），但不要在 recover 里再调用c.Abort
真正难的不是写一个 TrackMiddleware，而是想清楚哪个事件属于“请求进入即发生”，哪个必须等业务逻辑跑完才确定——生命周期埋点的本质，是把用户行为和代码执行路径对齐，而不是堆砌中间件层数。
