直接渲染万行表格会卡死大屏，因为浏览器并非为一次性挂载数万个设计，每增加一个都会触发dom构建、样式计算、布局和绘制，滚动时频繁重排，叠加高dpr下内存分配不均与gc延迟，导致首次加载超2秒、滚动卡顿甚至白屏。
为什么直接渲染万行表格会卡死大屏
因为浏览器不是为一次性挂载数万个 <tr> 设计的。每多一个 <code><tr>，就多一次 DOM 构建、样式计算、布局（Layout）和绘制（Paint）；滚动时还要反复触发重排。大屏设备通常分辨率高、DPR 高，但 CPU/GPU 资源并不比桌面机强，反而更容易因内存分配不均或 GC 延迟导致掉帧甚至白屏。<p>典型现象包括：首次加载延迟 >2s、滚动卡顿（</p>
<p>关键点在于：问题不在数据量本身，而在于你让浏览器把所有数据都当成“需要立即参与渲染”的节点来对待。</p>
<h3>用 DOM 复用池替代 createElement 每次新建</h3>
<p>高频刷新表格（如实时日志流、传感器数据）中，<code>document.createElement('tr') 是性能黑洞——它强制触发内存分配 + 样式树挂载 + layout → paint 全链路。复用池绕过这一整套开销，只做内容重置和位置更新。
实操建议：
-
recover()必须清空textContent和innerHTML，否则旧数据残留会导致错行或样式错乱 - 不要在
createFn里绑定事件监听器；应在取出后按需绑定，回收前用removeEventListener解绑 - 池大小建议设为可视区域行数 × 2～3（例如视口显示 20 行，池配 40～60 个
<tr>），过大反而拖慢 GC<li>对带 <code>dataset或内联样式的<td>，回收时也要重置 <code>node.dataset.key = ''和node.style.cssText = ''虚拟滚动必须配合固定行高与缓冲区计算
动态行高（如自动换行文本单元格）会让
startIndex = Math.floor(scrollTop / rowHeight)失效，导致错位、白屏或重复渲染。工业级方案要么预估平均高度并缓存实际高度（Layout Cache），要么强制统一行高——后者在大屏监控中更可控、更易调试。
html-to-pptx-converter下载使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
缓冲区（buffer）不是可选项。没有
bufferCount，用户快速滚动时会看到空白再闪现内容，体验断层。常见错误是只加顶部缓冲、忽略底部，结果滚到底部时最后一屏卡顿。核心参数建议：
-
rowHeight设为固定值（如48），避免运行时反复测量 -
bufferCount至少为Math.ceil(viewportHeight / rowHeight) + 2，保证上下各多渲染两屏 - 撑高容器用的
phantomHeight必须严格等于totalCount * rowHeight，否则滚动条比例失真 - 滚动监听必须用
requestAnimationFrame节流，而非直接写在onscroll里，否则在高刷屏上可能每帧触发多次计算
大屏特有陷阱：DPR、缩放与 canvas 混排坐标偏移
很多大屏部署在 4K/5K 分辨率设备上，
window.devicePixelRatio常为 2 或 3。若未适配，表格字体模糊、边框虚化、canvas 叠加图层鼠标事件错位——这不是代码逻辑错，是像素对齐没做。真实踩坑点：
- 用
getBoundingClientRect()获取坐标后，未除以devicePixelRatio就传给 canvas 绘制，导致文字偏移 1～2 像素 - CSS 缩放（
transform: scale(0.8)）后，scrollTop读数仍是原始值，但视口尺寸已变，公式里的viewportHeight必须用container.clientHeight动态读，不能硬编码 - 表格内嵌
<canvas></canvas>显示指标图时，若未设置canvas.width = canvas.offsetWidth * dpr和canvas.height = canvas.offsetHeight * dpr，图表会糊且抗锯齿失效 - 禁用
pointer-events: none的 SVG 底图后，未手动用getScreenCTM()映射坐标，导致点击热区漂移
这些细节不报错，但会让大屏上线后第一眼就“不够锐利”，排查起来又极耗时间。
-
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
