layui分页卡顿根源在于前端全量加载与冗余渲染，需关闭height未设、limit过大、loading:true三大陷阱，并由后端严格按page/limit分页返回合规数据。
别让 layui 分页扛大数据量——它默认的分页逻辑不是为万级数据设计的，卡顿根源在于前端全量加载、重复渲染和 DOM 膨胀。直接关掉 page: true 并不解决问题，关键得让分页行为与后端对齐、砍掉冗余渲染、避开主线程阻塞。
为什么 layui 分页一到几千条就卡？
常见现象包括：Uncaught RangeError: Maximum call stack size exceeded、滚动时表格“跳帧”、点击下一页白屏 2 秒、CPU 持续 90%+。这不是你数据慢，是 layui 在 page: true 下仍会遍历整个 res.data 做字段映射、格式化、even/odd 样式计算，哪怕只显示 50 条，内部也把全部响应数据过一遍。更糟的是，如果误用 data: [] + page: true，layui 会自己切片，但缓存、排序、搜索都失效，还多占内存。
必须关闭的三个默认陷阱
以下配置不手动关掉，其他优化基本无效：
-
height必须设为具体数值（如height: 500），否则虚拟滚动不启用，滚动卡死是必然 -
page设为true的同时，limit控制在 50–100，别设成 500 —— 后端一次返回太多行，前端拼 HTML 时间翻倍 -
loading: true禁用，它底层用setTimeout插入 loading dom，和真实渲染抢主线程，反而加剧抖动
后端接口必须配合分页参数
前端 url: '/api/list' 发出的请求，必须带 page 和 limit，且后端严格按这两个参数查库、返回对应页数据。不能出现：
- 前端发
page=2&limit=80，后端却忽略参数，返回全量 1w 行 - 后端返回的
count字段不准（比如漏统计软删除数据），导致分页器错乱、跳页失败 - 接口返回结构不符合 layui 要求：必须是
{"code":0,"msg":"","count":12345,"data":[{...}]}，缺count或类型不对（如 string）都会让分页器消失或报错
done 回调里接管 tbody 渲染（防闪烁关键）
不要依赖 layui 自动拼 tbody，万级数据下它的内部流程不可控。把实际插入逻辑挪进 done，用 DocumentFragment 批量写入：
table.render({
elem: '#demo',
height: 500,
url: '/api/list',
page: true,
limit: 80,
done: function(res, curr, count) {
const tbody = this.elem.next('.layui-table-box').find('tbody');
tbody.empty();
const frag = document.createDocumentFragment();
res.data.forEach(row => {
const tr = document.createElement('tr');
tr.innerHTML = `<td>${row.id}</td><td>${row.name}</td>`;
frag.appendChild(tr);
});
tbody[0].appendChild(frag);
}
});
注意：res.data 是当前页纯对象数组，别在里面调 JSON.stringify() 或嵌套循环；如果列多、字段深，提前在后端 flatten 结构，比前端处理快一个数量级。
真正难的不是怎么写完这几十行代码，而是后端是否真能稳定返回符合分页语义的数据——很多卡顿问题最后都定位到数据库没建好索引、count 查询超时、或分页 offset 模式在百万级表上退化。前端能做的边界很清晰：只拿该拿的，只画该画的，别替后端背锅。
