Layui 2.8 的 table.render() 默认不支持虚拟滚动，因其底层采用全量 DOM 渲染，缺乏 viewport 切片、滚动监听和动态行高计算等核心能力，属设计限制而非配置问题。
为什么 Layui 2.8 的 table.render() 默认不支持虚拟滚动
layui 2.8 的表格模块仍基于 dom 全量渲染，table.render() 会为每一条数据生成完整 <tr>，万级数据直接卡死或内存溢出。它没有内置的 viewport 切片、滚动监听、动态行高计算这些虚拟滚动必需能力——这不是配置开关能打开的功能，是底层设计限制。
<ul>
<li>真实场景下，哪怕只渲染 5000 行，Chrome 也常出现 300ms+ 首屏延迟和明显滚动掉帧</li>
<li>
<code>height 参数仅控制容器高度并启用原生滚动条，不改变渲染逻辑
done 回调手动销毁/重建 DOM 来“模拟”滚动，反而因频繁重排重绘更慢用 table.setRowData() + scroll 事件手动实现简易虚拟滚动
核心思路是：固定渲染可视区域（比如 20 行），滚动时实时计算起始索引，用 table.setRowData() 替换当前可见行的数据，同时保持表头、列宽、排序等状态不变。这绕过了全量渲染，但需你接管滚动位置与数据映射。
- 必须给表格容器加
overflow-y: auto和固定height，不能依赖 Layui 自动撑开 - 监听容器的
scroll事件，而非window—— Layui 表格滚动区是内部<div class="layui-table-box"> <li>每行高度需统一（如 <code>42px），否则无法准确算出当前应显示哪几行；用cellMinWidth防止文字撑高破坏一致性 - 示例关键片段：
const $box = $('.layui-table-box');<br>let start = 0, pageSize = 20;<br>$box.on('scroll', function() {<br> const scrollTop = this.scrollTop;<br> start = Math.floor(scrollTop / 42);<br> const sliceData = bigData.slice(start, start + pageSize);<br> table.setRowData('your-id', sliceData);<br>}); - 序号列（
type: 'numbers'）会显示错乱：必须在cols中用templet手动写start + index + 1，禁用内置序号 - 勾选状态丢失：不能依赖
table.checkStatus()，要自己用Map或对象缓存id → checked映射，并在每次setRowData后主动设置checked属性 - 排序失效：
table.sort()触发后，setRowData传入的数据必须已是排序后的切片，Layui 不会再帮你排序 - 真实万级场景中，90% 的需求其实是“快速定位+关键词过滤”，用
table.search()配合服务端模糊查询，比前端虚拟滚动更稳更快 - 若必须本地全量操作，优先考虑把数据转成
Worker处理，再用postMessage推给表格，避免主线程阻塞 - Layui 2.8 的
data是同步传入的，大数据量初始化时就会卡住，得用setTimeout分片加载或先 render 空表再异步 setRowData
table.setRowData() 的三个致命限制必须绕过
这个 API 看似可用，但直接调用会崩：它不重置序号列、不更新分页器、不维持已勾选行状态。万级数据下这些不是“体验问题”，而是功能断裂。
比“实现”更关键的是：什么情况下不该硬上虚拟滚动
如果后端能分页（哪怕一次查 200 条），就别在前端扛万级数据。Layui 2.8 的 DOM 模型决定了它不适合做复杂数据视图层——强行塞进去，后续导出 Excel、打印、列拖拽、树形表格都会陆续暴雷。
最常被忽略的一点：虚拟滚动后，table.cache 里永远只有当前 20 行，所有依赖 cache 的自定义逻辑（比如批量校验、跨页统计）必须重写，且无法复用 Layui 原生方法。
