layui表格卡顿的根本原因是前端分页模式下全量数据渲染dom，解决方案必须启用服务端分页：后端按page/limit查询并返回count和data，前端配置page:true及正确request/response映射。
为什么 layui.table.render() 渲染上千行数据会卡顿
不是 layui 本身写得烂，是它默认把全部数据塞进 dom 渲染——哪怕你只看前 20 行，它也把 1000 行全转成 <tr><td>...</td></tr> 插进去。浏览器重排重绘压力直接拉满，滚动卡、搜索卡、甚至点个复选框都延迟。
关键矛盾在于：Layui 的「前端分页」模式（page: false 或 page: { limit: 1000 }）本质是假分页，数据没切，只是靠 CSS 隐藏了后面的部分。
- 真实场景中，只要原始数据超过 500 行，且未开启服务端分页，基本就会肉眼可见卡顿
- 表格启用了
checkbox或radio列时，性能衰减更明显——每行多挂一个事件监听器 -
templet函数里做复杂计算（比如时间格式化、条件拼接字符串）会进一步拖慢渲染
必须开服务端分页，且后端要支持 limit 和 offset
Layui 表格真正的性能解法只有一条路：让后端每次只返回当前页的数据，而不是把全量数据一次性吐给前端。前端传 page 和 limit，后端按需查库，别偷懒用 SELECT * FROM xxx 再 JS 里 slice。
- 前端配置里必须设
page: true，并确保request对象里pageName和limitName与后端约定一致（常见是page和limit） - 后端接口返回结构必须含
count字段（总条数），否则 Layui 分页栏不显示页码 - 别信“我后端内存里有缓存，查全量很快”——快也没用，Layui 还是要把所有数据 render 成 DOM
示例请求参数：?page=2&limit=30；后端响应：{"code":0,"msg":"","count":1247,"data":[{...},{...}]}
cellMinWidth 和 minWidth 设太小会加剧重绘抖动
当列宽被设得过窄（比如 minWidth: 50），Layui 会在 resize 或滚动时频繁触发宽度重算，尤其在高 DPI 屏或缩放非 100% 时，DOM 尺寸反复微调，引发 layout thrashing。
- 建议所有列显式设置
minWidth≥ 80，文字类列可设120，操作列设160 - 禁用
cellMinWidth（默认为 60），它会让每单元格单独计算最小宽，开销翻倍 - 如果列内容长短差异大，优先用
templet控制内容截断（如return d.title?.substring(0,20)+'...'），而不是依赖自动换行撑高行高
禁用不必要的功能能省下 30%+ 渲染时间
很多项目开着 toolbar、totalRow、defaultToolbar 却根本不用，这些组件初始化时都要遍历所有数据做聚合或生成按钮，纯属白耗 CPU。
- 确认不用工具栏就删掉
toolbar配置项，别留空字符串或true -
totalRow: true会遍历整页数据求和/计数，若后端已返回统计值，前端别重复算 -
defaultToolbar默认带「导出」「打印」等按钮，但实际项目常屏蔽导出权限，却还保留配置，照样触发初始化逻辑 - 如果不需要排序，把每列的
sort: true全干掉；排序图标渲染和事件绑定也是开销
一个真实案例：关掉 totalRow + 去掉两列 sort + 清空 defaultToolbar，1200 行数据首屏渲染从 1.8s 降到 1.1s。
最麻烦的其实是后端没按规范返回分页参数，或者前端漏配 response 映射，导致 Layui 拿不到 count 就退化成前端分页——这种隐性退化最难排查。
