layui table的count属性非实时总行数，真实总行数应在done回调中获取count参数（服务端分页）或res.data.length（无分页），本地分页则用table.config.data.length。
layui table 实例的 count 属性不是实时总行数
直接读 table.config.count 或 table.cache[‘id’].length 得到的往往不是你想要的“当前表格展示的所有数据行数”——它可能是分页前的原始总数，也可能是缓存里残留的旧数据。真实场景中，用户关心的是：当前页渲染了几行？整个数据源一共有多少行？分页后还剩几页？这三个值经常被混用，但来源完全不同。
实操建议：
-
table.cache里存的是最近一次render或reload加载进来的原始数据数组，table.cache['yourId'].length是这次请求返回的**数据条数**（不含分页逻辑），适合做“本次加载共 X 条”的提示 - 表格 DOM 里实际渲染的
<tr> 行数，得用 <code>$('table .layui-table-body tbody tr').length，但注意：它包含空数据占位行（如“暂无数据”）、合并单元格行，不严谨 - 真正可靠的“当前页显示的有效数据行数”，是
table.config.data.length（如果用了本地分页）或通过done回调里的res参数拿到的data数组长度 - 把获取总行数的逻辑写进
done: function(res, curr, count) { ... }回调里，count参数就是服务端返回的总条数（分页模式下） - 如果后端没返回
count，就别依赖它；改用res.data.length，但要注意：这是当前页的数据量，不是总量 - 本地分页时，
table.config.data才是全量数据数组，table.config.data.length才是真实总行数 - 打开浏览器 Network 面板，点 reload，看接口响应体里有没有
count字段；没有就让后端加，或前端自己算（仅限数据量小、允许全量拉取） - 如果后端用的是自定义字段名，必须显式配置：
response: { countName: 'total' } - 不要在
reload的where里传count，那是请求参数，不会影响响应解析 - 放弃“初始化前获取”的想法，接受“首次 done 回调才是第一个可靠时机”
- 如果 UI 上必须立刻显示“共 0 条”，可以先 render 时设
count: 0，等 done 触发后再用$('#total-count').text(count)更新 - 避免在
render外部用setTimeout等 DOM 渲染，不稳定且不可靠
在 done 回调里拿总行数最稳妥
layui table 的 done 回调是唯一能同时拿到服务端响应、分页参数和当前渲染状态的地方。只要你没关分页，res 对象里一定有 count 字段（前提是后端按 layui 要求返回了该字段）；即使关了分页，res.data 就是全部数据，res.data.length 就是总行数。
常见错误现象：在 init 后立刻 console.log(table.config.count)，结果是 undefined 或老值——因为 config 还没被响应填充。
实操建议：
reload 之后总行数没更新？检查 count 是否随响应返回
调用 table.reload('id', {...}) 后发现 done 里的 count 没变，大概率是后端接口压根没返回 count 字段，或者字段名写错了（比如返回了 total 但配置里没设 response.countName: 'total'）。
使用场景：搜索、筛选后刷新表格，需要同步更新页码栏的“共 XX 条”文案。
实操建议：
表格初始化前就想知道总行数？做不到，除非提前请求
layui table 是异步渲染的，table.render() 执行完，DOM 和数据都还没就位。想在 render 前就知道总行数，唯一的办法是先发一次 AJAX 拿 count，再 render —— 但这违背了 table 的设计初衷，也多了一次请求。
性能影响：两次请求（一次只拿 count，一次拿数据）会拖慢首屏，尤其网络差时明显。
实操建议：
最容易被忽略的是：不同分页模式下，“总行数”的语义完全不同——服务端分页看响应 count，前端分页看 config.data.length，而 DOM 渲染行数只是视觉表现。混用这三者，八成会出错。
