layui分页limit参数无效如何排查

limit参数未发出是前端配置失效的第一信号，常见原因包括contentType设为application/json、where为字符串、request字段名不匹配等，需通过Network面板验证请求中是否含limit。

检查 Network 请求里有没有 limit 参数

limit 参数没发出去，是前端配置失效的第一信号。Layui 默认会把 limit 拼进 URL 查询参数（如 ?page=1&limit=30），但如果以下任一情况成立，它就会消失：

1. contentType: 'application/json' 被手动设了——这会让 layui 放弃 query string，又不自动把分页参数塞进 body，结果后端根本收不到 limit
2. where 写成了字符串（比如 where: 'a=1'）而不是对象（where: {a: 1}），导致 layui 无法安全合并分页参数
3. 用了 request 映射但字段名写错，比如 limitName: 'size'，但后端实际认的是 pageSize，参数名不匹配就等于没传

打开浏览器 Network 面板，点一次翻页，看请求 URL 或 Payload 里是否真实出现了 limit=xxx（或你映射后的字段名）。没有，就说明前端根本没发出去。

确认后端是否真按 limit 做了数据库分页

即使请求里带了 limit=100，后端如果只是查全量再用 .slice() 截取，Layui 的分页逻辑就会崩：

1. 返回的 count 字段还是总数（比如 5000），但每页只返回前 100 条，Layui 算出总页数是 50，实际翻到第 2 页就空了
2. 更隐蔽的问题：MySQL 的 LIMIT offset, size 没加，或者 ORM 没启用分页方法（如 ThinkPHP 的 paginate()、Spring Data 的 Pageable）
3. 接口文档里写的分页字段是 per_page，但你只配了 limitName: 'size'，漏映射 pageName，导致 page 参数也没传对

直接连数据库执行等效 SQL（比如 SELECT * FROM t LIMIT 100 OFFSET 100），验证返回条数和偏移是否符合预期。别信后端口头说“支持分页”。

排查 limit 值是否被初始化覆盖或类型错误

Layui 的 limit 是硬编码 fallback 为 10 的，不是配置项默认值——这意味着它极易被忽略或写错：

1. limit: "30"（字符串）会导致请求参数变成 limit=30&limit= 这种错乱格式，后端解析失败
2. 写了 limits: [10, 20, 50] 却漏掉 limit: 50，表格首次渲染仍是 10 条，下拉菜单虽有 50 选项，但当前页不生效
3. 用 table.reload() 切换条数时，只传 { limit: 50 }，没同步传 page: { curr: 1 }，导致当前页码还是第 3 页，但后端按新 limit 计算 offset 出错，数据重复或跳变

检查初始化配置里 limit 是否存在、是否为数字、是否在 limits 数组中。reload 时必须显式带 limit，Layui 不会从 DOM 下拉框里自动读取当前选中值。

验证 parseData 是否意外覆盖了 limit 行为

当后端响应结构不标准（比如 { code: 0, data: { list: [], count: 100 } }），你用了 parseData 提取数据，很容易在这里埋雷：

1. parseData 返回对象里漏了 count 字段，Layui 会认为总数为 0，直接隐藏分页栏
2. 返回了 count: "100"（字符串），Layui 内部判断非数字，放弃分页计算，表现就是页码按钮全灰
3. 在 parseData 里手动改了 limit（比如 return { data: res.data.list, count: res.data.count, limit: 20 }），但这个 limit 字段 layui 完全不认，纯属无效赋值

parseData 只负责返回 data 和 count 两个字段，其他键名一律被忽略。它的唯一作用是“把脏响应洗干净”，不是用来干预分页逻辑的入口。

最常被忽略的点：Layui 的 limit 是个单向控制参数——它只决定“我要多少条”，不决定“我能不能拿到”。只要后端没按这个数真正切片、没返回准确的 count、没在请求里收到它，前端无论怎么调配置，都只是在 UI 上自欺欺人。