obj.dataIndex不等于原始数据索引，因其仅表示当前页table.cache中的下标；而cache内容受分页、筛选、排序影响，已非原始数据全集，须依赖后端返回的唯一标识（如id）准确定位原始记录。
不能直接用 obj.dataindex 或 d.lay_table_index 当作原始接口数据的索引——它们只反映当前页缓存中的位置，原始数据可能已分页、过滤、排序，甚至根本没全量加载。
为什么 obj.dataIndex 不等于原始数据索引
layui 的 obj.dataIndex 是当前页渲染数据在 table.cache['id'] 中的下标，而 table.cache 里存的是服务端返回的当前页数据（或前端分页时的当前页切片），不是原始全量数组。比如你原始接口返回 1000 条，当前页是第 3 页、每页 20 条，那 table.cache 里只有第 41–60 条，obj.dataIndex = 5 对应的是这 20 条里的第 6 条，即原始数据的第 46 条——但你没法单靠这个数字反推，除非你知道服务端怎么分页。
- 服务端分页时，原始数据索引完全由后端控制，前端无从得知
- 前端分页（
page: false或data直接传数组）时，table.cache等于原始数组，此时obj.dataIndex才等价于原始索引 - 只要调用过
table.reload()并带where参数做过筛选，table.cache就是过滤后的新数组，原始索引进一步丢失
服务端分页场景：必须让后端返回唯一标识字段
这是唯一可靠方式。不要试图“算”原始索引，而是依赖业务主键或后端生成的全局序号（如 id、uuid、row_number）。你在表格列中显式定义该字段（哪怕 hide: true），然后在事件里直接取：
table.on('row(userTable)', function(obj){
var id = obj.data.id; // 后端返回的唯一标识
console.log('原始数据中第 ' + id + ' 条记录被点击');
});
- 避免用数据库自增
id做分页序号——它不等于“第几条”，尤其有软删除或并发插入时 - 推荐后端在分页响应里加一个
original_index字段，值为(curr - 1) * limit + row_number_in_page，前端直接读取 - 如果后端不配合，且你必须知道原始顺序位置，只能改用前端分页（把全部数据一次拉回），但要注意性能和内存占用
前端分页场景：可安全使用 obj.dataIndex
当你初始化表格时用的是本地 data 数组（而非 url），且没调用 reload 带筛选参数，那么 table.cache['id'] 就是原始数组的浅拷贝，obj.dataIndex 就是原始数组下标：
var originalData = [
{id: 101, name: 'Alice'},
{id: 102, name: 'Bob'},
{id: 103, name: 'Charlie'}
];
<p>table.render({
elem: '#demo',
data: originalData,
cols: [[{field: 'name', title: '姓名'}]],
id: 'demoTable'
});</p><p>table.on('row(demoTable)', function(obj){
var originalIndex = obj.dataIndex; // 就是 0、1、2...
console.log('原始数组第', originalIndex, '项:', originalData[originalIndex]);
});
- 一旦你调用
table.reload({ where: {status: 'active'} })，table.cache就变成过滤后的新数组，obj.dataIndex指向新数组下标，与原始数组脱钩 - 排序（
sort）不影响索引对应关系，因为排序只是重排table.cache，不改变其元素引用
真正难的不是“怎么取”，而是想清楚你要的“原始索引”到底指什么：是数据库主键？是接口返回顺序？还是分页前的全局行号？不同语义对应完全不同的解法，混用必然出错。后端字段永远比前端计算靠谱。
