必须用performanceobserver早期注册监听largest-contentful-paint类型获取lcp，因lcp可能在dom解析中途触发，延迟注册会漏收；entry.starttime才是标准时间戳，需用其判断并降级，且须兼容safari等不支持场景。
LCP 数据必须用 PerformanceObserver 监听 largest-contentful-paint 类型获取，不能靠 performance.getEntriesByName('largest-contentful-paint') 主动查——后者在首次触发前返回空数组，且无法捕获后续动态更新的 LCP 元素。
为什么必须 early register（页面早期注册）
LCP 可能在 DOM 解析中途就触发（比如一张大图刚解码完成），如果脚本加载晚、注册 observer 晚，就会漏掉首屏关键 LCP 事件。浏览器不会为已发生的 entry 补发通知。
- 最佳位置是 HTML
内的内联<script></script>，或至少在开头立即执行 - 避免放在
window.addEventListener('load', ...)或document.addEventListener('DOMContentLoaded', ...)里——此时 LCP 很可能早已发生 - 若用模块化构建（如 Webpack/Vite），需确保该 observer 的 chunk 被标记为
priority: 'high'或设为preconnect提前加载
entry.startTime 是真实 LCP 时间，别用 entry.renderTime
entry.renderTime 在部分旧版 Chrome（≤105）中存在兼容性问题，且规范已将其废弃；entry.startTime 才是标准字段，表示该元素内容实际渲染到屏幕的时间戳（毫秒，相对于 navigationStart）。
- 上报或判断时只依赖
entry.startTime，例如：if (entry.startTime > 2500) { /* 触发降级 */ } -
entry.size是渲染像素面积，和性能无关，不能用于“是否卡顿”的判断 -
entry.element可能为null（如图片跨域未设置crossorigin），不要直接操作 DOM，先做存在性检查
如何避免重复上报和主线程阻塞
LCP 可能因动态内容插入（如 SSR 后 hydrate、图片懒加载完成）而多次触发，但你通常只关心「最终稳定值」；同时回调里执行重操作会拖慢 TTI。
- 用布尔变量
lcpReported标记是否已上报，首次触发后置为true，后续忽略（除非明确需要跟踪变化） - 避免在回调里调用
fetch、遍历大量节点、或修改样式——改用setTimeout(() => { /* 轻量上报 */ }, 0)或queueMicrotask - 使用
buffered: true确保能捕获注册前已发生的 LCP（仅对 navigation、paint、resource 等部分类型有效；largest-contentful-paint类型在 Chromium 中支持 buffered，但 Safari 目前不支持，需额外 fallback
兼容性兜底：Safari 和老版本 Chrome 怎么办
Safari ≤16.4 不支持 largest-contentful-paint 类型监听，且 PerformanceObserver 对该类型的支持晚于其他指标。不能假设它一定可用。
- 注册前先检测：
if ('largest-contentful-paint' in PerformanceObserver.supportedEntryTypes) - 不支持时，可退回到基于
PerformancePaintTiming的启发式估算：监听paint类型，取entry.name === 'largest-contentful-paint'的 entry（但注意：这在 Safari 中也无效，实际只能 fallback 到 FCP + 人工埋点） - 服务端聚合时，需单独标记来源浏览器，避免把 Safari 的缺失数据误判为性能异常
真正难的不是注册 observer，而是处理 LCP 触发后的响应逻辑——比如 Canvas 动画降级要清循环引用，CSS 动画要切 class 而非删 style，这些细节一旦漏掉，监控数据再准也没用。
