limits数组仅控制下拉选项，不改变默认每页条数；limit字段需显式设置且必须与limits中某值一致，否则下拉无法回显、页码文案异常。
limits 数组只控制下拉选项，不决定当前显示多少条
很多人以为配了 limits: [10, 20, 50] 就自动变成每页 10 条，结果首次加载还是 30 条——因为 limit 字段没显式设置。layui 的 limits 纯粹是给分页栏下拉菜单提供可选项，它不会覆盖默认行为。
实操建议：
-
limit必须是正整数，且要和limits中某个值一致，否则下拉菜单无法回显当前选中项 - 推荐写法：
page: { limit: 10, limits: [10, 20, 50, 100] }，别用page: true简写，否则limit回退到默认 30 - 移动端慎用过多选项，
limits超过 4 个（如[5, 10, 15, 20, 30]）容易导致下拉弹层被截断，用户点不到最末选项
后端参数名不是 limit 时，必须用 request 映射
前端发请求默认带 ?page=1&limit=10，但 Spring Boot 接口常收 pageNum/pageSize，ThinkPHP 用 page/list_rows，Django 可能是 offset/limit 或 per_page。参数名对不上，后端就收不到 limit 值，永远按默认条数查。
实操建议：
- 用
request: { limitName: 'pageSize' }把前端limit映射成后端认的字段 - 如果后端页码参数也不同（比如叫
currentPage），一并映射：request: { pageName: 'currentPage', limitName: 'pageSize' } - 打开浏览器 Network 面板，检查实际请求 URL 中的参数名是否匹配，这是最直接的验证方式
动态改 limits 列表或当前 limit 值，别 destroy 再 render
用户点击按钮切换「每页 50 条」，你调了 table.destroy() 再重新 table.render()，这会导致表格事件丢失、工具栏按钮失效、分页状态错乱——尤其是带 toolbar 模板或自定义操作列时。
实操建议：
- 统一用
table.reload('id', { page: { limit: 50 } })，reload 会保留所有初始化配置，只更新你传进去的部分 - 如果同时要重置页码（比如从第 5 页切到每页 100 条后想回到第 1 页），加
curr: 1：page: { limit: 100, curr: 1 } - reload 不会自动读取页面上已选中的下拉值，得手动取 DOM 值或维护一个变量，再塞进
page.limit
limits 选项太多或太小，会影响分页栏渲染和用户体验
设 limits: [1, 2, 3, 5, 8, 13, 21] 这种斐波那契数列？或者全塞进 [10, 20, 50, 100, 200, 500, 1000]？前者会让用户困惑，后者在小屏上根本点不全，而且大数值往往只用于导出场景，不该混在常规分页控件里。
实操建议：
- 常规列表推荐
[10, 20, 50, 100]；管理后台可加200；导出类操作单独放按钮，不走limits - 避免
limit设为 1 或 2——分页意义丧失，滚动成本反而更高；也别设超过 200，渲染压力陡增，尤其列多、单元格内容复杂时 - 如果业务真需要超大页（如 5000 条/页），优先考虑后端流式导出接口，而不是让表格硬扛
limit: 15 但 limits 里没有 15，分页栏可能不显示「当前第 x 页，共 y 页」文字，连带导致跳转输入框（skip）失效——这不是 bug，是 Layui 的 layout 渲染逻辑依赖两者一致性。
