page.limits数组才是控制下拉选项的唯一配置，request.limit仅传递条数给后端，不参与前端渲染；limits必须为数字数组（如[10,20,50]），长度≥2才渲染可展开下拉框，空数组[]才彻底隐藏。
page.limits 数组才是控制下拉选项的唯一配置
改 request.limit 没用，它只负责把当前条数作为参数发给后端，不参与前端下拉菜单渲染。真正决定「能选哪些值」的是 page.limits 数组，比如 [10, 20, 50, 100] —— 这个数组里有几个数字，下拉框就显示几个选项。
常见错误现象：limits: ["10", "20"]（字符串数组）、limits: null 或直接省略该字段，结果下拉菜单还是默认的 [10, 20, 30, 40, 50]。
-
limits必须是数字数组，不能是字符串、null或undefined - 如果只写
limit: 15却没配limits，下拉菜单仍按默认值渲染，只是初始选中项变成 15（但用户点不开） -
limit的值必须在limits数组中存在，否则 UI 会自动 fallback 到第一个值，且不报错
想隐藏下拉框？设 limits: [] 才真正生效
Layui 的逻辑很明确：只要 limits.length >= 2，就渲染可展开的下拉；length === 1 时，渲染一个带箭头但无法点击的输入框（视觉上还在）；只有 limits: [] 才彻底跳过 DOM 渲染。
别信“设一个值就行”，实测无效。也别用 limits: [15]，它会生成一个假下拉，占位还容易被误点。
- 隐藏后如需动态改条数，必须用
table.reload('id', { page: { limit: 50 } })，不能只改配置再 render -
table.destroy()+render()会丢失当前页码、排序状态、已绑定事件，属于过度操作 - 若表格启用了
done回调并手动绑了事件，destroy不会自动解绑，得自己清理
动态切换 limits 需要销毁重绘，不能 reload
Layui 表格不支持运行时替换 limits 数组。调用 table.reload() 传入新 limits 完全无效 —— 它只会更新数据和分页参数，UI 层的下拉菜单 DOM 和内部状态不会同步。
正确做法是先销毁，再用新配置重新渲染：
table.destroy('demo');
table.render({
elem: '#demo',
url: '/api/list',
page: {
limits: [5, 15, 30],
limit: 15
}
});
-
table.destroy()必须传入正确的 ID（即容器的lay-id或id属性值），否则销毁失败，后续render会报 “重复渲染” 错误 - 销毁前建议清空容器内非表格 DOM（如自定义按钮、提示文字），避免残留节点干扰样式
- 如果表格有外部绑定的排序、工具栏事件，需在
destroy后手动重新绑定
后端参数名不匹配会导致 limit 值发错但 UI 看不出问题
前端设了 limits: [10, 20, 50]，用户选了 20，表格也刷新了，但后端返回的还是 30 条——大概率是后端接口期待的字段名不是 limit，比如叫 pageSize 或 size。
这时候光配 page.limit 没用，得靠 request.limitName 映射过去：
table.render({
elem: '#demo',
url: '/api/list',
page: { limits: [10, 20, 50], limit: 20 },
request: { limitName: 'pageSize' }
});
- 务必打开浏览器 Network 面板，确认实际请求 URL 中的参数名和值是否符合预期
- 如果后端还要其他字段（如总条数字段叫
total_count），一并用response.countName映射 - 移动端慎用过长的
limits数组（如[5, 10, 15, 20, 30, 50, 100]），弹层易超出视口，用户点不到末尾选项
最常被忽略的一点：Layui 的 limits 是纯前端控制项，它不校验后端是否真能返回对应数量的数据。如果后端分页逻辑有 bug（比如 offset 计算漏了 (curr - 1) * limit），前端一切正常，但数据永远对不上。
