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