lay-num列分页后从1开始是因为它仅表示当前页内行序号，非全局序号；需用templet结合page、limit与LAY_TABLE_INDEX手动计算全局序号：(page-1)*limit+data.LAY_TABLE_INDEX+1。
layui table 的 lay-num 列为什么分页后从 1 开始？
因为 lay-num 是 layui 内置的「当前页序号」，它只对当前页数据重新编号，不感知总数据量和分页位置。这不是 bug，是设计如此——它本质是 index + 1（当前行在本页的索引），不是全局序号。
用 templet 手动算全局序号最稳
必须放弃 lay-num，改用自定义列 + templet 函数计算。核心逻辑：用表格的 page 和 limit 推出当前页起始序号，再加行索引。
-
page是当前页码（从 1 开始），limit是每页条数，起始序号 =(page - 1) * limit + 1 - 在
templet里拿到data.LAY_TABLE_INDEX（当前页内索引，从 0 开始），所以全局序号 =(page - 1) * limit + data.LAY_TABLE_INDEX + 1 - 注意：这个值依赖于后端返回的
page和count正确，否则翻页错乱
col: [{type: 'numbers', title: '序号', width: 60, templet: function(d) {
var page = layui.table.cache['yourTableId'].page || 1;
var limit = layui.table.cache['yourTableId'].limit || 10;
return (page - 1) * limit + d.LAY_TABLE_INDEX + 1;
}}]后端传 pageNum 和 pageSize 时别漏了 count
layui 分页依赖响应里的 count 字段算总页数。如果后端只返回当前页数据、没传 count，page 就拿不到或为 undefined，导致序号全算成 1。
- 接口返回结构必须含
count（总记录数），不能只靠前端猜 - 如果用
url模式请求，确保后端返回字段名匹配：{"code":0,"msg":"","count":123,"data":[...]} - 若用
data模式（前端分页），page和limit会是undefined，此时只能用layui.table.cache读取已缓存的配置，或改用服务端分页
移动端或快速翻页时序号闪动？加个防抖判断
表格重绘时 layui.table.cache 可能还没更新，page 暂时还是上一页的值，导致序号短暂错乱。
- 不要直接读
layui.table.cache['id'].page，改用layui.table.config['id'].page（更实时） - 或者在
templet里 fallback：如果page不可信，就用layui.table.get('yourTableId').config.page.curr - 极端情况可加
setTimeout延迟取值，但优先检查是否漏了done回调里重载逻辑
layui 表格的全局序号不是配置开关，它得靠你把分页上下文和行索引串起来——少一个参数，序号就断一次。
