漏斗必须基于用户可感知且业务可归因的动作节点（如page_view、cta_rendered等），强制携带user_id/session_id/trace_id，附带web-vitals指标，配置有序性与合理时间窗口，并确保前后端trace_id全链路对齐。
不能只靠 performance.mark() 和 performance.measure() 构建漏斗——它们没有用户上下文、不带业务语义、无法排除伪转化，直接上报等于白打点。
漏斗节点必须是“用户可感知+业务可归因”的动作
把 navigationStart 到 loadEventEnd 当第一步，本质是在测浏览器加载，不是测用户是否留下。真实流失常发生在按钮渲染后不可点、表单提交后无反馈、跳转链接 404 这类场景。
必须定义明确的业务事件节点，例如：
-
page_view：首屏核心内容（如 banner + 主标题）IntersectionObserver可见且持续 100ms -
cta_rendered：关键按钮 DOM 存在 +getComputedStyle(el).display !== 'none' -
cta_clicked：绑定在目标元素上的原生 click 事件，非委托（避免误捕父级冒泡） -
api_success：仅当接口返回 HTTP 200 且 响应体含success: true字段才触发 -
next_page_loaded：目标页navigationComplete（即performance.getEntriesByType('navigation')[0].loadEventEnd）
每个节点打点时，强制携带 user_id、session_id、trace_id —— 缺一不可。否则日志服务里根本串不起完整路径。
立即学习“前端免费学习笔记（深入）”；
web-vitals 指标只能当质量标尺，不能当漏斗步骤
把 LCP 单独设为一步，会把“LCP 很快但按钮没渲染”的用户错误计入成功；把 FID 当成独立节点，又会漏掉“FID 合格但按钮点击后无响应”的交互断点。
正确做法是：在每个业务节点打点时，附带上当前已采集的 web-vitals 值，例如：
track('cta_rendered', {
user_id: 'u_123',
session_id: 's_456',
trace_id: 't_789',
lcp_ms: 1240,
fid_ms: 18,
cls: 0.03
});
后续在日志平台中可直接筛选：cta_rendered AND cls > 0.1 → 查这些会话里有多少没走到 cta_clicked，就能定位布局抖动是否导致误点或放弃。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
注意：CLS 必须用 layout-shift 类型 PerformanceEntry 上报，而非仅依赖 getCLS() 聚合值，否则丢失时间戳，无法对齐业务节点。
漏斗配置必须启用“有序”+限定时间窗口
前端行为天然有时序约束。若配置漏斗时未勾选“有序”，api_success 出现在 cta_clicked 之前也会被算作转化，这实际是埋点错位或异步逻辑 bug。
时间窗口设置常见错误：
- 设成 7 天：用户第 1 天进首页、第 3 天才点击，被计入漏斗，但上下文早已断裂
- 设成 1 秒：网络延迟或低端机执行慢，
cta_clicked稍晚触发就被丢弃
推荐按业务流长度设定：
- 单页内操作（如表单提交→结果页）：30 秒
- 跨页流程（如商品页→下单页→支付页）：120 秒
- 含人工决策环节（如试听课预约→出席）：按业务规则定，但需在埋点时记录
expected_next_step_at时间戳，用于后期校验合理性
全链路日志对齐的关键陷阱
前端漏斗数据要真正有用，必须和后端 trace 对得上。常见断点：
- 前端传的
trace_id没透传到 API 请求 header（如漏了X-Trace-ID） - 后端生成新 trace_id 覆盖了前端传入的（尤其在网关层或中间件中）
- 日志采集 SDK 自动截断过长字段，
trace_id被截成前 16 位，导致无法关联
验证方法：在 Chrome Network 面板找一个 cta_clicked 后发出的请求，检查其 request header 是否含完整 trace_id，再查后端日志中该 trace_id 是否出现对应 api_success 记录。差一位都不行。
最易被忽略的是：前端打点时间戳用的是 Date.now()，而后端用的是系统纳秒级时间，两者未做时区/精度对齐，会导致日志平台排序错乱——建议统一用 performance.timeOrigin 做相对时间打点，再由后端服务统一注入绝对时间。
