必须通过PerformanceObserver监听layout-shift类型获取CLS，因其他方式无法捕获浏览器内部重排/重绘引发的偏移量；Chrome、Edge、Firefox已稳定支持，Safari 16.4+才开始支持。
如何监听 layout-shift 类型的性能条目
页面布局偏移（CLS）必须通过 PerformanceObserver 监听 layout-shift 类型获取，其他方式（如轮询 getComputedStyle 或 MutationObserver）无法捕获浏览器内部重排/重绘引发的偏移量。Chrome、Edge、Firefox 均已稳定支持该类型，但 Safari 16.4+ 才开始提供（iOS 16.4+ 对应），低版本 Safari 会静默忽略 observe 调用。
注册时需注意：
-
entryTypes: ["layout-shift"]必须显式声明，不能混在["paint", "navigation"]等数组里靠“兼容性兜底” - 回调中每个
entry的value是单次偏移得分（0～1），hadRecentInput字段决定是否计入 CLS 总分（用户刚交互过则忽略该次） - 不要依赖
entry.sources数组——它仅在 Chrome 中实验性存在，且内容为简化后的 DOM 节点快照（无 classList、无 computedStyle），字段名可能随时变更
怎样定位导致偏移的具体 DOM 元素
entry 本身不直接包含元素引用，但可通过 entry.sources（若存在）或结合 performance.getEntriesByType("resource") 交叉推断。更可靠的做法是：在监听到偏移后，立即遍历 document.querySelectorAll("*") 中尺寸/位置突变的候选元素（需加防抖）。
实操建议：
- 只检查
offsetWidth/offsetHeight在 100ms 内变化 > 5px 的元素，避免全量遍历开销 - 优先过滤带
img、iframe、video、div[role="banner"]等高风险标签或属性的节点 - 上报时记录
entry.startTime、entry.value、entry.hadRecentInput和匹配到的node.tagName+node.id（若有），不传完整 outerHTML
为什么不能直接上报原始 layout-shift 条目
单次滚动或图片加载可能触发数十个 layout-shift 条目，每个条目 value 很小（如 0.002），但累积后才构成真实 CLS。直接上报原始条目会导致：
- 服务端日志膨胀：1 秒内密集偏移可产生 30+ 条，且无业务上下文
- 无法关联用户行为：不知道偏移发生在「点击按钮后」还是「首屏渲染中」
- CLS 计算失效：服务端无法按规范剔除
hadRecentInput === true的条目
必须在前端聚合：以 5 秒为窗口，累加 value，记录最大单次 value 和对应 startTime，仅当窗口内总和 ≥ 0.1 或单次 ≥ 0.05 时才触发上报。
上报前必须做的兼容性与降级处理
不是所有环境都支持 layout-shift。需主动检测并 fallback：
- 用
"layoutShift" in PerformanceObserver.supportedEntryTypes判断是否可用（注意拼写是layoutShift，不是layout-shift） - 不支持时，可退化为监听
resize+scroll事件，配合requestAnimationFrame检测视口内元素位置跳变（精度低但能捕获明显抖动） - 上报 payload 中必须带
observerSupport: true/false字段，服务端据此分流处理逻辑 - 避免在 Web Worker 或 iframe 中初始化 observer——
layout-shift只在主文档上下文中触发
真正难的是把零散的偏移事件映射到具体业务模块。比如 banner 图片异步加载导致下方文案下移，这个因果链需要结合资源加载时间、DOM 插入时机、样式计算耗时三者比对，不能只靠 observer 单点数据。
