虚拟滚动是解决大数据量表格卡顿的唯一可靠方案，需监听scroll事件手动计算可视区域、固定行高、精确控制dom节点复用与定位，避免强制同步布局和内存泄漏。
直接用 display: none 或删 DOM 节点来“隐藏”行，解决不了卡顿——10 万行 DOM 仍在内存里，浏览器照样重排、照样崩。真要撑住大数据量，必须用虚拟滚动：只创建视口内 + 缓冲区的行，其余完全不进 DOM。
为什么不能靠 IntersectionObserver 控制表格滚动
它响应慢、精度差，无法在滚动过程中实时给出“当前第几行在顶部”。比如用户快速拖动滚动条，IntersectionObserver 可能只触发一两次回调，中间跳过的索引根本抓不到，导致内容空白或错位。实际项目中，99% 的稳定虚拟表格都监听 scroll 事件 + 手动算 scrollTop。
- 滚动是高频连续行为，
scroll事件可每帧触发（需节流），IntersectionObserver是异步批量回调，天生不适合 -
IntersectionObserver依赖元素进入/离开视口，但虚拟表格里大部分 DOM 根本不存在，没法被观察 - 它不提供像素级偏移，无法支撑
top或transform: translateY()的精确定位
rowHeight 必须固定，否则代价陡增
一旦行高不一致，你就得为每一行缓存 getBoundingClientRect().top，首次渲染就要遍历全部数据做测量；窗口缩放、字体加载完成、动态展开行等场景还会触发重测，CPU 和内存压力直线上升。多数业务表格其实可以约束为固定行高（比如统一 40px），这是最值得做的妥协。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 若真要支持可变高度，优先考虑服务端预计算每行高度并随数据下发，避免前端运行时测量
- 不要在
scroll回调里反复调用getBoundingClientRect()，它会强制同步布局，直接拖垮帧率 - 用
ResizeObserver监听容器尺寸变化后，才重新计算可视范围，而不是每次滚动都重算
占位容器的 position 和 top 偏移必须配对使用
常见错误是给外层容器设了 position: relative，但忘了让内部渲染区域用 position: absolute + top 定位；或者误用 transform: translateY() 替代 top，在某些 Chrome 版本中会意外触发合成层切换，反而更卡。
- 占位
div高度必须是data.length * rowHeight，且父容器需设position: relative - 真实渲染的
table或tbody必须是position: absolute，用top: ${startIndex * rowHeight}px对齐位置 - 别用
innerHTML = newRows全量替换，应复用已有tr节点、仅更新textContent或dataset，避免事件绑定重复和内存泄漏
真正让虚拟表格在生产环境不崩的，往往不是“怎么画出来”，而是缩放后是否重算可视行数、键盘 PageDown 是否同步滚动位置、IE11 下 scrollTop 是否取整异常——这些细节漏一个，10 万行就可能白屏或卡死。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
