必须在 page.layout 中显式包含 'count' 才显示总条数，且需配合 response.countName 或 parseData 正确提取后端总数字段，最终通过 done 回调的 count 参数获取真实值。
page.layout 里漏了 'count' 就不会显示总条数
layui 默认只渲染「上一页」「下一页」和页码，count（共 xx 条）不是自动开启的。必须在 page.layout 数组里显式写上 'count'，否则不管后端返回什么，界面上都看不到总数。
常见错误是只写了 ['prev', 'page', 'next'] 或干脆省略 layout——这时候 count 字段再准也没用。
-
page: { layout: ['count', 'prev', 'page', 'next', 'limit', 'skip'] }是最稳妥的写法，缺一不可 - 如果不需要跳转输入框，可以去掉
'skip'，但'count'必须存在 -
layout顺序不影响功能，但建议按常用顺序排列，方便后续维护
后端字段名不是 count 时，得配 response.countName
layui 默认只认响应体里的 count 字段。Spring Boot 常返回 total，Django 可能返回 count 但嵌套在 data 下，NestJS 甚至可能是 pagination.total——这些都会导致总数不显示。
- 字段名是
total？加配置：response: { countName: 'total' } - 字段在深层对象里，比如
{ data: { list: [], pagination: { total: 100 } } }？countName无法处理，必须用parseData -
parseData是最终兜底逻辑，哪怕只改字段名，底层也是靠它提取，所以务必检查是否return了正确结构
示例：parseData: res => ({ data: res.data.list, count: res.data.pagination.total })
parseData 没 return 或结构不对，count 就是 undefined
只要用了分页，layui 就会走 parseData 函数。即使你只配了 response.countName，它内部也是通过 parseData 转换的。一旦这个函数没 return，或返回对象里没有 count 属性，分页栏的总数就为空。
- 检查函数末尾有没有
return，尤其注意异步逻辑里容易漏掉 - 返回结构必须是
{ data: [...], count: 123 }，不能是{ list: [...], total: 123 } - 调试时可在
parseData里加console.log(res)，确认原始响应结构
done 回调里 count 参数才是真实总条数
别依赖 table.config.count 或渲染前读取的变量——它们往往滞后或未初始化。真正可靠的总条数，是在 done 回调的第三个参数里传进来的。
done: (res, curr, count) => { console.log('真实总条数：', count); }- 这个
count是经过parseData提取、且和服务端一致的值，可用于动态更新其他 UI 元素 - 如果这里
count是undefined或0，说明parseData没提取成功，或后端根本没返回总数字段
复杂点在于：字段名、嵌套层级、parseData 返回结构、layout 配置这四者必须全部对齐，漏掉任何一个环节，count 就消失。
