Layui分页中limit必须显式设置为正整数且需在limits数组中，否则默认30条；limits长度≥2才渲染可交互下拉框；reload时须同步重置curr避免数据错位；后端参数名需通过request映射匹配。
limit 必须显式设为最大值，不能靠 limits 推导
layui 不会从 limits 数组里自动选最大值当默认条数。哪怕你写了 limits: [10, 20, 50, 100]，只要没写 limit: 100，首次渲染还是按默认的 30 条来。
常见错误是只配了 limits 就以为完事，结果用户打开页面第一眼看到的仍是 30 条，下拉菜单虽然有 100 这个选项，但当前页没生效。
-
limit必须是正整数，不能是字符串（比如"100"）、null或undefined - 如果
limit值不在limits数组中，下拉菜单无法回显，UI 会悄悄 fallback 到limits[0]，且不报错 - 推荐写法：
page: { limit: 100, limits: [10, 20, 50, 100] }，两个都显式写死
limits 数组长度影响下拉是否可展开
limits 不只是“可选项列表”，它直接控制前端 UI 行为：只有 limits.length >= 2 时，分页栏才会渲染成可点击的下拉框；limits.length === 1 会渲染一个带箭头但点不动的输入框；limits: [] 才真正隐藏下拉。
想让用户一上来就看到最大条数，又不想暴露太多选项？别用 limits: [100] —— 它生成的是假下拉，占位还容易误点。正确做法是设 limits: [100] 加上 limit: 100，再配合 CSS 隐藏下拉箭头（但注意这属于 hack，非官方支持）。
- 移动端慎用过多选项，
limits超过 4 个（如[5, 10, 20, 50, 100]）容易导致弹层被视口截断 - 后端若不支持大条数查询（比如 MySQL 的
LIMIT 10000, 100性能差），前端设再大也没用，得和后端对齐上限
reload 改 limit 时必须重置 curr，否则页码错乱
用户点按钮切换“每页 100 条”，你调 table.reload('id', { page: { limit: 100 } })，Layui 默认保留当前页码（比如第 3 页）。但后端按新 limit 算偏移量时，第 3 页对应的是 (3 - 1) * 100 = 200 起始位置，而旧逻辑可能是 (3 - 1) * 30 = 60，数据直接错位。
Network 面板里能看到请求参数仍是 ?page=3&limit=100，但返回的数据块跟预期不匹配，轻则空数据，重则重复或漏行。
- 正确 reload 写法：
table.reload('id', { page: { limit: 100, curr: 1 } })，强制回到第一页 - 如果业务要求保持当前页（比如用户正在看第 5 页，只想改条数），后端必须同步支持按新 limit 重新计算 offset，并返回对应区间数据
- 千万别用
table.destroy()+table.render()替代 reload —— 事件绑定、toolbar 模板、排序状态全丢
后端字段名不匹配会让 limit 形同虚设
前端设了 limit: 100，下拉也选了 100，表格刷新了，但实际返回的还是 30 条——大概率是后端没收到 limit 参数。
Layui 默认发 ?page=1&limit=100，但 Spring Boot 常用 pageNum/pageSize，ThinkPHP 用 page/list_rows，Django 可能是 offset/limit 或 per_page。参数名对不上，后端就当没这回事。
- 映射写法：
request: { pageName: 'pageNum', limitName: 'pageSize' } - 最可靠验证方式：打开浏览器 Network 面板，点分页或切换条数，看请求 URL 里出现的到底是
limit=100还是pageSize=100 - 后端响应里的
count字段也得按新limit重新算总页数，否则分页栏显示“共 2 页”，点第二页却加载失败
真正麻烦的是后端接了参数但没加 SQL LIMIT，Layui 会在前端截取前 N 条，但 count 是全量总数，分页器会多出几十页空白按钮——这种问题光看前端配置发现不了，得查后端日志和 SQL 执行计划。
