layui 表格默认每页显示 10 条。如果想修改默认分页条数，正确写法是仅使用 page: { limit: 20 }，并且这里必须传数字。limits 只负责控制分页下拉框里的可选项，不会影响首次加载的默认条数；如果在 reload 时修改了 limit，必须同时把 curr 设为 1，否则很容易出现分页数据错位。另外，后端也要和前端的 limitName 保持一致，比如 pageSize，并把分页查询逻辑处理正确。
page.limit 必须显式写正整数，不能省略或写成字符串
很多人会把 layui 表格的默认 limit 记成 30，但实际上并不是。它的默认值是 10，而且这个数值是源码里写死的兜底值。也就是说，只要没有在 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 不会自动推导，也不会回退到数组中的最大项。
真正起作用的是 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。这两个地方一旦出错，页面看起来正常，数据实际上已经不对了。
