在 layui table 的 row 事件中，用 $(obj.tr).index() 获取当前页内从 0 开始的行号；dataindex 不可靠，因排序、筛选、重载等操作会导致其错乱；全局序号需结合 page.curr 和 limit 计算，但服务端分页时应由后端返回。
layui table 的 row 事件里怎么拿到当前行的序号（从 0 开始）
layui 表格本身不直接在 row 或 rowdouble 回调里传入行号，但你可以通过 tr 元素在 tbody 中的位置推算出来。关键是别误用 dataindex —— 它是渲染时的内部索引，翻页后会变，不是你想要的“当前页第几行”。
实操建议：
- 监听
row事件时，用tr参数调用$(tr).index()，它返回的是该<tr> 在当前 <code><tbody> 内的下标（从 0 开始）<li>确保表格已渲染完成再绑定事件，推荐在 <code>table.render()的done回调之后绑定，或用table.on('row(...)') - 如果启用了分页，这个索引只代表「当前页内」的行号；如需全局唯一序号（比如第 127 行），得手动计算：
当前页码 × 每页条数 + tr.index() - 点击第一页第 3 行，
dataIndex === 2；翻到第二页再点第 3 行，dataIndex还是2，而不是12（假设每页 10 条） - 调用
table.reload({ where: { keyword: 'xxx' } })后，所有dataIndex重排，但顺序和你传入的数据数组不一致 - 表格配置了
id: 'myTable'，某些低版本 layui 会把dataIndex当成 DOM ID 使用，导致冲突或丢失
为什么 dataIndex 不可靠，什么时候会出错
dataIndex 是 layui 渲染时给每行数据临时加的属性，初始值可能和原始数组下标一致，但一旦触发排序、筛选、重载（table.reload()）、甚至某些版本中开启 id 配置后，它就容易错乱或重复。你点第二页某行，dataIndex 可能还是 5、6、7……根本不是页内位置。
常见错误现象：
用 tr.index() 获取页内行号的完整写法
这是最轻量、兼容性最好、也最不容易翻车的做法。不需要额外维护状态，也不依赖 layui 内部字段。
table.on('row(test)', function(obj){
var $tr = $(obj.tr);
var rowIndexInPage = $tr.index(); // ✅ 当前页内从 0 开始的行号
var rowData = obj.data;
<p>console.log('当前页第', rowIndexInPage, '行，数据：', rowData);
});</p>
注意点：
-
obj.tr是原生 DOM 元素，必须用$()包一层才能调用index() - 不要写成
$(obj.tr).parent().index()——那是<tbody> 在整个表格里的位置，没意义<li>如果表格有固定列（<code>fixed: true），tr会被复制到多个<tbody>，此时 <code>$(tr).index()仍返回它所在<tbody> 的位置，不影响页内逻辑<h3>需要全局行号时，怎么安全计算</h3> <p>如果你的业务真要“第 N 条数据在整个数据集中的位置”，就得自己算。别信 <code>dataIndex，也别硬编码页码——要用表格实例的实时状态。实操建议：
- 先用
table.cache['test']拿到当前缓存的全部原始数据（注意：仅限未开启服务端分页时有效） - 启用服务端分页时，必须靠后端返回全局序号（比如字段
global_index），前端无法准确推导 - 如果坚持前端算，可用：
var page = table.config['test'].page; var limit = table.config['test'].limit; var globalIndex = (page.curr - 1) * limit + $tr.index();
真正麻烦的地方在于：分页 + 排序 + 筛选三者叠加时，前端根本不知道服务端到底返回了哪一批数据。这时候所谓“全局行号”已经失去意义——除非后端明确支持并返回。
- 先用
