直接渲染万行表格会卡死大屏，因为浏览器并非为一次性挂载数万个设计，每增加一个都会触发dom构建、样式计算、布局和绘制，滚动时频繁重排，叠加高dpr下内存分配不均与gc延迟，导致首次加载超2秒、滚动卡顿甚至白屏。
为什么直接渲染万行表格会卡死大屏
因为浏览器不是为一次性挂载数万个 <tr> 设计的。每多一个 <code><tr>，就触发一次 DOM 构建、样式计算、layout 和 paint；滚动时还要反复重排。大屏高 DPR 下内存分配不均 + GC 延迟，首次加载超 2s、滚动掉帧甚至白屏是常态。<p>关键不在数据量，而在你让浏览器把所有行都当成“必须立刻渲染”的节点对待。</p>
<ul>
<li>典型错误：用 <code>innerHTML 或循环 appendChild 渲染全部数据
Shadow DOM 必须配合虚拟滚动和节点复用池
单独用 attachShadow 不会提速。真正起效的是：在 Shadow DOM 内部实现虚拟滚动 + DOM 复用池，把实际挂载的 <tr> 控制在可视区域行数 × 2～3 范围内。<ul>
<li>固定 <code>rowHeight（如 48），避免动态测量导致计算失效
bufferCount 至少设为 Math.ceil(viewportHeight / rowHeight) + 2，上下各多两屏phantomHeight 必须严格等于 totalCount * rowHeight，否则滚动条比例失真createFn 不要绑定事件；recover 必须清空 textContent、innerHTML、dataset 和 style.cssText
自定义元素中如何安全注入动态数据
模板本身不支持数据绑定，所有插值必须手动操作 DOM 节点。重点不是“怎么填”，而是“在哪填”和“怎么防错”。
- 在
connectedCallback中批量渲染，而非构造函数里——此时元素已挂载，可安全访问shadowRoot - 若用 Shadow DOM，务必先调用
this.attachShadow({ mode: 'open' })，否则克隆后可能触发非法请求 - 按钮等交互节点，应在克隆后立即绑定事件，不要依赖事件委托（因 Shadow DOM 隔离）
-
<template></template>克隆出的节点默认保留原始id，多个实例会导致 ID 冲突。推荐模板中用占位符如id="item-title-{id}"，克隆后用正则替换
delegatesFocus 是无障碍聚焦的关键开关
delegatesFocus 必须在 attachShadow 时声明，它是创建 shadow root 的一次性配置，创建后不可读写。
- 错误写法：
host.shadowRoot.delegatesFocus = true—— 控制台无报错但无效 - 正确写法：
this.attachShadow({ mode: 'open', delegatesFocus: true }) - 开启后，外部点击或 Tab 导航能穿透 shadow boundary 聚焦内部元素，但前提是：内部至少有一个可聚焦元素（
<input>、<button></button>或tabindex="0"），且未被disabled或hidden - 宿主不会自动触发
focus/blur事件，需手动桥接：在内部可聚焦元素上监听，再通过setAttribute('focused', '')同步状态
复杂点在于：既要控制节点数量，又要保证焦点流、ID 唯一性、事件清理和样式隔离——四者缺一不可。漏掉任意一项，都可能在大屏监控或无障碍测试中暴露问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
