beego框架不内置用户行为埋点能力，需手动集成或通过中间件实现；仅依赖finish钩子会遗漏前端交互行为、panic时丢失埋点、页面id推导易错，应采用前端采集→中转api→异步落库的三层结构，由trackcontroller快速响应并异步处理，避免污染业务日志与监控。
Beego 框架本身不内置用户行为埋点能力，必须手动集成或借助中间件实现；直接依赖 Beego 的 Controller 生命周期钩子（如 Prepare）是最轻量、最可控的起点。
为什么不能只靠 Beego 的 Finish 钩子做埋点
很多人默认在 Finish 方法里统一记录请求耗时、状态码等基础指标，但用户真实行为（如点击「提交订单」、滚动到文章底部、播放视频 30 秒）往往发生在前端交互层，后端无从感知。仅靠 Finish 只能拿到 HTTP 层面的“结果”，漏掉大量关键路径节点。
- 前端触发的行为需通过额外 API 上报（如
/api/track），不能混进业务接口逻辑里 -
Finish在 panic 后可能不执行，导致埋点丢失；需配合defer+recover补救 - 若用
Finish记录页面级曝光，需从Controller.Data["Layout"]或路由名反推页面 ID，易出错且难维护
推荐的三层埋点结构：前端采集 → 中转 API → 异步落库
Beego 作为后端服务，只承担中转和持久化角色，避免阻塞主业务链路。不要在 Prepare 或 Post 里同步写 MongoDB / Kafka —— 会拖慢所有接口响应。
- 前端用轻量 SDK（如自研
track.js）发送 POST 到/v1/track，携带event、page_id、props（JSON 字符串）、ts（毫秒时间戳） - Beego 新建
TrackController，禁用 XSRF 和自动渲染：this.DisableRender = true，快速接收并校验字段长度、格式（如event是否在白名单内） - 校验通过后，立即返回 204，然后用
goroutine异步调用logTrackAsync(...)写入消息队列（如 Kafka）或本地日志文件；不要直连数据库
如何避免埋点数据污染业务日志和监控
Beego 默认把所有请求打到 accesslog，但埋点接口流量大、模式固定，混在一起会导致日志膨胀、Prometheus 指标失真（比如把 /v1/track 当成核心接口统计 QPS）。
- 在
app.conf中关闭埋点路由的日志：log.AccessLogs = false，并在main.go初始化时对/v1/track单独设置beego.BeeLogger.DelLogger("access") - 用独立的
track日志器：beego.NewLogger(1000)，输出到logs/track.log，便于后续用 Filebeat 采集 - 如果用了 OpenTelemetry，务必在
TrackController中显式禁用 trace：otel.GetTextMapPropagator().Extract(ctx, propagation.HeaderCarrier(r.Header))后跳过 span 创建，否则每个埋点都生成一条无意义 trace
真正难的不是“怎么记”，而是“记什么”和“怎么查”。Beego 没有类似 Gin 的 gin-swagger 自动标注埋点参数，所有事件定义、字段约束、上下游约定都得靠文档和 Code Review 控制——一旦前端传错 page_id 格式，后端很难实时发现。
