lay-num列分页后从1开始是因为它是layui内置的当前页序号，仅基于本页数据索引（i+1）生成，不关联总数据量或页码信息，本质是当前页内行索引加1。
layui表格的lay-num列为什么分页后从1开始？
因为lay-num是 layui 内置的序号列，它只对当前页数据做递增，不感知总数据量和当前页码。本质是渲染时对data.length做for (let i = 0; i ，所以每页都从1起步。
用templet手动算全局序号（推荐）
在列定义中不用type: "numbers"或lay-num，改用templet函数，结合page配置算出真实序号：
table.render({
elem: '#demo',
url: '/api/list',
page: { layout: ['count', 'prev', 'page', 'next'], curr: 1, limit: 10 },
cols: [[
{ title: '序号', width: 60, templet: function(d) {
const page = table.config['demo'].page;
const limit = table.config['demo'].limit;
return (page - 1) * limit + d.LAY_TABLE_INDEX + 1;
}
},
{ field: 'name', title: '姓名' }
]]
});注意：d.LAY_TABLE_INDEX是从0开始的当前页内索引，必须配合当前页码和每页条数才能得出全局序号。
-
table.config['demo']中的demo要替换成你表格容器的id值（不含#） - 如果用了
request自定义参数，page和limit可能不在table.config里，建议把它们存到闭包或外部变量中 - 服务端返回数据时若已带
id字段，直接用d.id更稳妥，但要注意ID是否连续、是否含逻辑删除数据
服务端返回row_number比前端算更可靠
当排序、搜索、权限过滤导致前端无法准确推算序号时，让后端在 SQL 中加ROW_NUMBER() OVER (ORDER BY ...)或等效逻辑，把序号作为字段返回（比如叫seq），前端直接渲染：
{ field: 'seq', title: '序号', width: 60 }这样不受分页、排序、筛选影响，也避免前端重复计算。尤其适用于多条件动态查询场景。
- MySQL 8.0+、PostgreSQL、SQL Server 支持窗口函数；低版本 MySQL 可用变量模拟，但需注意并发安全
- 返回字段名别用
index或number，容易和 layui 内部字段冲突 - 如果后端已返回主键
id且业务上就是自然序号，可直接用id，但要确认它没被跳号或重用
禁用lay-num并避免fixed: "left"干扰
有人尝试给lay-num列加fixed: "left"再配templet，结果序号错乱——这是因为fixed列会单独渲染一次，d.LAY_TABLE_INDEX值可能异常。正确做法是：
- 彻底不用
type: "numbers"或lay-num="true" - 所有序号列走
templet，且不设fixed - 如需固定首列，把序号列放在第一列，其他列
fixed: "left"时避开它
真正麻烦的不是怎么写，而是忘记LAY_TABLE_INDEX只是页内索引，以及忽略服务端排序后前端重排导致序号和实际顺序不一致——这种时候，唯一靠谱的序号只能来自后端。
