shadow dom 本身不提供性能监控能力，必须在组件 js 生命周期中主动打点（如 lit 的 update/updated 钩子），因 performanceobserver 作用于全局文档，无法区分 shadow root 内部渲染事件，且其不生成独立 performance entry 类型。
Shadow DOM 本身不提供性能监控能力，它只是隔离样式和结构的容器；要监控组件性能，必须在 Shadow DOM 内主动注入测量逻辑或通过外部钩子捕获其生命周期事件。
为什么直接用 PerformanceObserver 监控 Shadow DOM 渲染无效
浏览器的 PerformanceObserver（如监听 paint 或 layout-shift）作用于全局文档，无法区分某次重绘是否由某个 Shadow Root 内部触发。你看到的 largest-contentful-paint 时间戳可能对应主文档中一个 <img>，而非你自定义的 my-card 组件内部的 slot 插入。
常见错误现象：
– 在 connectedCallback 里注册 PerformanceObserver，却发现回调从不触发与该组件相关的 element 字段；
– 使用 performance.mark() 打点后，performance.getEntriesByName() 返回空数组——因为 mark 名称未被显式保留或跨上下文丢失。
- 关键原因：Shadow DOM 不改变浏览器渲染流水线，也不生成独立的 performance entry 类型
- 真正能挂钩的只有组件自身的 JS 执行时机（如
render()开始/结束、updated钩子） - 若组件使用
Declarative Shadow DOM（即 HTML 中直接写shadowrootmode="open"），首次解析阶段无法插入 JS 测量代码
在 Lit / Polymer / Vanilla Web Components 中打点的实操方式
以 Lit 为例，性能监控必须嵌入到模板更新周期中，而不是依赖 DOM 树观察。Lit 的 shouldUpdate → update → updated 是唯一可控的三段式时机。
实操建议：
- 在
update()开头调用performance.mark('my-card-update-start')，结尾调用performance.mark('my-card-update-end') - 在
updated()中用performance.measure()计算耗时：performance.measure('my-card render', 'my-card-update-start', 'my-card-update-end') - 避免在
render()中直接打点——它可能被多次调用且不保证执行完成（例如异步模板暂停） - 若组件含大量
slot内容，需额外监听slotchange事件并单独计时，因为 slot 分发是异步且延迟触发的
示例片段：
update(changedProperties) {
performance.mark('my-card-update-start');
super.update(changedProperties);
performance.mark('my-card-update-end');
}
updated() {
performance.measure('my-card render', 'my-card-update-start', 'my-card-update-end');
this.shadowRoot.querySelector('slot').addEventListener('slotchange', () => {
performance.mark('my-card-slot-ready');
});
}
如何识别 Shadow DOM 内部的强制同步布局（forced reflow）
这是最容易被忽略的性能杀手：看似封装良好的组件，却因读取 offsetHeight、getComputedStyle 等触发 layout thrashing。由于 Shadow DOM 的样式隔离，getComputedStyle 返回的是该 Shadow Root 内的计算值，但依然会触发完整 layout。
使用场景：
– 组件需要根据子元素尺寸动态调整高度（如折叠面板）
– 基于 clientRect 实现 tooltip 定位
- 检测方法：打开 Chrome DevTools → Rendering → 勾选 “Layout Shift Regions” 和 “FPS Meter”，然后交互触发组件更新，观察是否出现黄色 layout 帧
- 安全替代：用
ResizeObserver替代轮询offsetHeight；用IntersectionObserver替代getBoundingClientRect()判断可见性 - 特别注意：在
connectedCallback中立即读取this.shadowRoot.querySelector('.item').offsetTop—— 此时元素尚未 layout，会强制同步计算，应推迟到requestAnimationFrame回调中
真正的难点不在 Shadow DOM 是否“可见”，而在于它的边界让开发者误以为样式和布局也被完全隔离了；实际上，reflow 和 repaint 仍是全局行为，只是触发源藏得更深而已。
