能，但必须手动累加、过滤并解析 sources；注册 PerformanceObserver 需用 layout-shift 类型且 buffered: true，尽早执行于 head 中；仅累加 hadRecentInput 为 false 的 entry.value，并通过 entry.sources 或 DevTools 时间轴定位抖动源。
能，但必须手动累加、过滤并解析 sources，否则只拿到一个空白数值，定位不到具体元素。
注册 PerformanceObserver 时必须用 layout-shift 类型且开启 buffered: true
浏览器不会等你 JS 加载完才记录 layout-shift；首屏关键偏移往往发生在 DOMContentLoaded 前。不设 buffered: true，observer 启动后就收不到历史条目。
- 必须在
<head>内或document.write阶段尽早执行，越晚注册漏掉的偏移越多 -
type: 'layout-shift'是唯一能捕获单次偏移细节的类型，getCLS()等封装函数底层也靠它 - 不加
buffered: true就像打开监控摄像头前没按录像键——画面全丢了
entry.hadRecentInput === false 是 CLS 累加的硬性过滤条件
CLS 只统计「非用户触发」的偏移。如果用户刚点过按钮、滑过滚动条，500ms 内发生的位移会被忽略（hadRecentInput === true），否则会误判交互反馈为“抖动”。
- 每次拿到
entry，第一件事就是检查entry.hadRecentInput，为true的直接跳过 -
entry.value是本次偏移对 CLS 的贡献值（浮点数），需手动累加到全局变量中 - 别信
entry.name === 'layout-shift'就代表要计入——它只是事件名，不是计分开关
entry.sources 数组才是定位抖动源的关键，但常为空或含 null 节点
entry.sources 是一个 LayoutShiftAttribution[]，每个对象带 node（发生突变的 DOM 元素）和 previousRect/currentRect（偏移前后布局框）。但它不稳定：
-
node为null很常见：匿名文本节点、跨 shadow root、或元素已被 GC 回收 - 此时得结合
entry.startTime（毫秒时间戳）去 DevTools → Rendering → Layout Shift Regions 查对应时间点的红色高亮区域 - 优先查
node?.tagName是否为IMG、IFRAME、DIV（广告容器）、SPAN（字体替换导致的文本重排） - 用
node?.ownerDocument?.defaultView?.getComputedStyle(node)看width、height、position是否在加载/渲染中突变
生产环境上报时务必传 { reportAllChanges: true, includeSources: true }
web-vitals 库的 getCLS() 默认只上报最终稳定值，且 includeSources: false 时 sources 永远为空数组——这等于关掉了定位能力。
- 调试阶段用：
getCLS({ reportAllChanges: true, includeSources: true }) - 生产上报时也要保留
includeSources: true，哪怕只采样 1% 用户，至少能拿到真实抖动元素的 tagName 和位置信息 - 注意：开启
includeSources会增加序列化开销，但比起定位失败的成本，这点性能损失可接受
真正卡住人的不是监听逻辑，而是 sources 为空时不知道该回头查 DevTools 时间轴，或误把 hadRecentInput === true 的 entry 当作有效抖动源去修——结果白调半天 CSS，问题还在用户手机上跳。
