layui分页count未显示的主因是后端字段名非顶层count或嵌套过深，需用response.countname或parsedata手动提取；同时须对齐前后端limit参数、reload时同步更新count，并确保page.layout含'count'且parsedata返回正确结构。
后端返回的 count 字段没被 layui 正确读取
最常见原因是后端响应 JSON 里总条数字段名不是 count，比如叫 total、records 或嵌套在 data.pagination.total 里。layui 默认只认顶层的 count，其他名字一律忽略，导致分页栏显示“共 0 条”或翻页按钮失效。
解决方式分两层：
- 如果字段名只是不同（如
total），加response: { countName: 'total' } - 如果字段嵌套较深（如
{ data: { list: [...], pagination: { total: 123 } } }），必须用parseData手动提取：parseData: function(res) { return { count: res.data.pagination.total, data: res.data.list }; }
注意：parseData 是必经逻辑，哪怕只改 countName，底层也是靠它兜底——所以优先检查这个函数有没有执行、有没有 return 正确结构。
前端传的 limit 和后端实际 limit 不一致
layui 用 Math.ceil(count / limit) 算总页数。如果前端 limit: 20，但后端分页插件（如 PageHelper）实际按 pageNum=1, pageSize=10 查询，那返回的 count 就是按每页 10 条算的总数，和前端除不尽，总页数就会少一半甚至错乱。
关键要对齐：
- 确保后端接收参数名和 layui 一致：
page和limit（不是pageNum/pageSize） - PageHelper 启动时写
PageHelper.startPage(page, limit)，别手动转 - MyBatis-Plus 直接用
new Page(page, limit)，它原生兼容
否则会出现“后端说共 100 条、每页 20 → 应有 5 页”，但实际查出来只有 40 条数据，因为后端误用了 pageSize=10。
table.reload() 时 count 没同步更新
搜索或筛选后，后端返回新 count，但前端 reload 时没把新值带进去，表格仍按旧 count 渲染，导致页码栏显示“共 5 页”，点第 5 页却加载失败或空白。
根本问题在于：reload 不会自动读取响应里的 count 更新分页逻辑，它只负责发请求+渲染 data，总页数计算仍依赖初始化时的 count 或上一次缓存值。
正确做法：
- 在
done回调里拿到最新res.count，存到变量或全局状态 - 下次 reload 前，显式传入
page: { curr: Math.min(curr, Math.ceil(newCount / limit)) } - 千万别在
done里立刻 reload —— 此时 DOM 还没刷新，table.cache也未更新，容易误判
尤其要注意：如果用了 table.setRowChecked() 或其它影响缓存的操作，table.cache 可能滞后，此时依赖它的页码计算不可靠。
分页栏 layout 缺了 'count' 或 parseData 返回结构错误
即使后端返回了正确的 count，分页栏也不显示“共 xx 条”，大概率是 page.layout 里漏写了 'count'，或者 parseData 返回的对象里没有 count 字段（比如拼错了大小写，写成 Count）。
检查项很具体：
-
page: { layout: ['count', 'prev', 'page', 'next', 'limit', 'skip'] }——'count'必须显式存在 -
parseData函数返回对象必须含count（数字类型）和data（数组）两个 key，缺一不可 - 浏览器 Network 面板里看响应体，确认原始 JSON 确实含
count字段且值为数字（不是字符串 "100"）
最容易被忽略的是：某些后端框架（如 NestJS）默认把分页信息放在 pagination.total，而开发者只配了 countName 却没意识到它不支持路径写法，结果白配——这种场景只能靠 parseData 解决。
