layui表格默认limit为10，正确写法仅page: { limit: 20 }且必须为数字；limits仅控制下拉选项，不影响首次加载；reload改limit须同步设curr=1，否则数据错位；后端需匹配limitName（如pageSize）并正确分页。
page.limit 必须显式写正整数，不能省略或写成字符串
layui 表格默认 limit 是 10（不是 30，源码硬编码 fallback 值），但很多人误以为是 30。只要没在 page 对象里写 limit，就一定会走这个 10。常见错误包括：limit: "20"、limit: null、把 limit 写在顶层配置里（如 { limit: 20, url: '' }），这些全无效。
正确写法只有一种：page: { limit: 20 }，且 20 必须是数字类型。如果用 page: true 初始化，limit 字段必须和它同级显式声明，否则照样回退到 10。
- 初始化时漏掉
limit→ 首次加载永远是 10 条 -
limits: [10, 20, 50]却不配limit: 20→ 下拉有 20 这个选项，但第一页还是 10 条 - 后端返回数据条数没变？先检查 Network 里请求 URL 是否带
&limit=20
limits 数组不等于默认值，只是控制下拉菜单可选项
page.limits 只干一件事：决定分页栏下拉框里显示哪些数字。它完全不影响首次加载条数，也不参与数据请求逻辑。很多人配了 limits: [5, 10, 20, 50] 就以为默认会选最大值，其实 layui 不会自动推导，也不会 fallback 到数组最大项。
真正起作用的是 page.limit 的值，而且它必须出现在 limits 数组里，否则 UI 会悄悄回退到第一个值（比如 limits: [10, 20, 50] 但 limit: 15 → 实际生效的是 10），还不报错。
-
limits长度必须 ≥ 2 才渲染可点击下拉；limits: [20]会生成一个点不动的假输入框 - 想彻底隐藏下拉？唯一可靠方式是
limits: []，再配合固定limit - 移动端慎用超过 4 个选项，弹层容易被视口截断
reload 时改 limit 必须同步重置 curr，否则数据错位
用户点下拉选“每页 50 条”，你调 table.reload('id', { page: { limit: 50 } })，Layui 默认保留当前页码（比如第 3 页）。但后端按新 limit 计算偏移量时，(3 - 1) × 50 = 100，而旧逻辑可能是 (3 - 1) × 10 = 20，结果返回的数据块完全对不上——轻则空白，重则重复或漏行。
Network 面板能看到请求参数是 ?page=3&limit=50，但返回内容跟预期不符，问题就出在这里。
- 通用做法：
table.reload('id', { page: { limit: 50, curr: 1 } })，强制回到第一页 - 如果业务要求保持当前页（比如用户正在看第 5 页），后端必须支持按新
limit重新计算 offset 并返回对应区间数据 - 千万别用
table.destroy()+table.render()替代 reload —— 排序状态、toolbar 模板、已绑定事件全丢
后端参数名不匹配会导致 limit 白设
前端写了 limit: 20，但表格数据没变，大概率是后端根本没收到这个值。Layui 默认用字段名 limit 发请求，但 Spring Boot、ThinkPHP 等框架常期待 pageSize 或 size。
这时候光改前端没用，请求发出去的还是 &limit=20，后端直接忽略。
- 必须用
request: { limitName: 'pageSize' }映射参数名 - 同时确认后端响应里的总条数字段（默认
count）是否准确，否则分页按钮可能灰掉或页码错乱 - 最隐蔽的坑：后端接到了
pageSize=20，但数据库查询没加LIMIT，结果返回全量数据 → Layui 只截前 20 条，但总页数计算全崩
实际改 limit 最容易被忽略的点，是认为 limits 数组能影响默认行为，或者 reload 时只传 limit 不管 curr。这两个地方一错，页面看着正常，数据早就不对了。
