tbody必须唯一且存在，拆分会导致频繁重排；应采用虚拟滚动，仅渲染视口内行，用DocumentFragment批量操作、IntersectionObserver监听锚点、稳定key复用节点，并依赖服务端返回total/offset动态设置tbody高度。
长表格滚动时 tbody 拆分会导致 DOM 重排卡顿
直接用多个 <tbody> 拼接长表格，看似能“分段加载”，但实际会触发浏览器频繁重排——尤其在 scroll 事件中动态插入新 <tbody> 时，整个表格的 layout tree 都可能被强制刷新。这不是分段加载，是分段拖慢。
真正可行的路径只有一条：保持单个 <tbody>，用虚拟滚动（virtual scrolling）控制可见行的渲染范围。
- 只渲染视口内 ±20 行，其余用
height占位（不创建<tr>） -
<tbody>始终存在且唯一，scrollTop变化时仅更新innerHTML或 patch 差异行 - 避免对
<tbody>频繁appendChild/replaceChild，改用DocumentFragment批量操作
用 IntersectionObserver 替代 scroll 监听 tbody 可见性
监听整个 <tbody> 是否进入视口，比监听 window.onscroll 更轻量、更精准，且天然支持惰性加载边界判断。
关键点在于：不能把 <tbody> 当作观察目标（它通常高度极大，几乎永远在视口内），而应观察其内部的“占位锚点”：
- 在
<tbody>开头插入一个<tr class="anchor-top"></tr>，底部插入<tr class="anchor-bottom"></tr> - 用
IntersectionObserver观察这两个锚点，当anchor-bottom进入视口 200px 时，触发下一批数据拉取 - 加载完成后，用
documentFragment插入新<tr>，并更新anchor-bottom的offsetTop位置
这样既避开 scroll 节流陷阱，又让加载时机可预测、可调试。
tbody 内部 tr 需要 key 属性才能高效复用
即使你手写 DOM 操作，没加稳定 key（比如用数据 id 绑定到 data-key 或 id 属性），浏览器就无法判断哪一行该复用、哪一行该重绘。结果就是每次刷新都全量重建 <tr>，性能归零。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
实操建议：
- 每行
<tr>必须带唯一id或data-key，值来自原始数据项的不可变标识（如user.id） - 批量更新前，先遍历现有
<tr>，用Map缓存key → DOM node映射 - 新数据到来后，按
key查表复用节点，仅更新<td>文本或 class，不替换整行 - 删除行时，只调用
node.remove()，不手动清空 innerHTML
服务端分页响应必须带 total 和 offset 字段
前端虚拟滚动依赖精确的“已加载范围”和“总长度”，如果后端只返回 data: [...] ，前端根本不知道还剩多少没拉、当前是否到底。没有 total，就无法计算滚动条 thumb 高度；没有 offset（或 page + limit），就无法构造下一页请求。
典型错误响应：
{"data": [{"id":1,"name":"A"}, {"id":2,"name":"B"}]}正确响应应含：
{"data": [...], "total": 12847, "offset": 200, "limit": 100}否则，你写的“分段加载”只是假象——用户滚到底部时，要么无限加载，要么突然空白，因为前端失去了位置坐标系。
最易被忽略的是：tbody 高度必须由 total * rowHeight 动态设置，且 rowHeight 要取真实渲染后的 clientHeight（不能硬写 48px），否则滚动条拖拽错位、快速滚动跳帧。
