直接用 performanceobserver 监听 layout-shift 事件可捕获偏移原始数据，但需设 buffered: true 才能获取历史条目；sourceelement 是定位异常元素首要线索，为空时回退 affectedelements；须按秒聚合上报、避免逐条发送，并结合业务语义判断用户感知异常。
直接用 PerformanceObserver 监听 layout-shift 类型事件，就能实时捕获每次布局偏移，包括触发元素、偏移量、影响范围等原始数据；但要注意，它只上报“发生了偏移”，不自动识别“异常渲染元素”——这需要你结合 entry.sourceElement、entry.value 和视口位置做二次判断。
监听 layout-shift 事件必须设置 buffered: true
CLS 是累计值，浏览器只在页面生命周期内持续累积，但默认情况下 PerformanceObserver 不会回溯已发生的偏移事件。若脚本加载晚于首屏渲染（比如异步加载的监控 SDK），就会漏掉关键前几帧的偏移。
- 务必在
observe()中传入{type: 'layout-shift', buffered: true}，否则只能捕获后续新增事件 -
buffered: true会让浏览器把历史layout-shift条目推入回调，但仅限当前页面会话中尚未被 GC 的条目（通常覆盖首屏到用户离开前） - 不支持跨页面/SPA 路由切换后的延续，每个新页面需重新注册 observer
如何从 entry 中定位“异常渲染元素”
entry.sourceElement 是最直接线索，但它有局限：不是每次偏移都有值（例如由 CSS 动画或 JS 修改 transform 引起的偏移可能为空），且它指向的是“最后修改 DOM 的元素”，未必是视觉上跳动最明显的那个。
- 优先检查
entry.sourceElement是否存在且可访问（注意跨 iframe 场景下可能为null） - 若为空，回退到
entry.affectedElements（Chrome 120+ 支持），它返回一个Element[]列表，更贴近实际位移元素 - 结合
entry.value（单次偏移得分）和entry.startTime，过滤出value > 0.01且发生在用户可感知区域（getBoundingClientRect()在视口内）的条目 - 避免只依赖
sourceElement.tagName做归类——IMG可能只是占位失败的表象，根因常是父容器缺失aspect-ratio或未设宽高
上报时必须聚合，不能逐条发请求
一次页面滚动或图片加载可能触发数十次小偏移，如果每条 layout-shift 都立即 fetch 上报，极易触发节流、丢失数据，甚至拖慢主线程。
- 用
requestIdleCallback或setTimeout(..., 0)延迟聚合，避免阻塞渲染 - 按
entry.startTime的秒级时间戳分桶，每秒最多上报一次聚合数据（含该秒内最大单次value、涉及元素个数、sourceElement的 tagName 分布） - 上报 payload 中保留至少一个典型
sourceElement的序列化快照：element.tagName + '#' + element.id + '.' + Array.from(element.classList).join('.') + ' rect:' + JSON.stringify(element.getBoundingClientRect()) - 不要在上报逻辑里调用
console.log或任何可能触发重排的操作，否则会制造新的layout-shift
真正难的不是监听到偏移，而是区分“技术上发生偏移”和“用户感知为异常”。比如一个 position: fixed 的悬浮按钮在页面滚动时微调位置，entry.value 可能很小，但若它遮挡了用户正要点击的 CTA，就是高优先级问题——这类上下文语义，PerformanceObserver 给不了，得靠你结合业务埋点补全。
