table.cache['id']是获取当前页首尾数据的唯一可靠来源，必须在done回调后读取，且需判空处理；禁用分页时缓存为全量数据，DOM或LAY_TABLE_INDEX等均不可靠。
table.cache['id'] 是唯一可信来源
当前页的第一条和最后一条数据，必须从 table.cache['yourTableId'] 数组取，不能查 DOM、不能读 table.config.page.curr、也不能依赖 obj.dataIndex（那是事件内单行索引）。因为只有 table.cache 存的是当前页真实渲染的原始数据副本——无论你是否启用了服务端分页、排序或搜索，它都已按当前状态过滤并切片完毕。
但要注意：这个数组只在 done 回调执行后才就绪。如果在 render() 后立刻读，table.cache['id'] 很可能还是 undefined 或空数组。
- 确保表格初始化时传了
id: 'myTable'，否则缓存键名不匹配 - 不要在
render()调用后立即访问，得等done触发或监听table.on('done(id)', ...) - 如果表格禁用了分页（
page: false），table.cache['id']就是全部数据，此时“当前页首尾”语义失效，需另行判断
获取首尾数据的正确写法
拿到缓存数组后，首尾就是下标 0 和 length - 1，但必须先判空：
const cache = table.cache['myTable'] || []; const firstRow = cache.length > 0 ? cache[0] : null; const lastRow = cache.length > 0 ? cache[cache.length - 1] : null;
这段代码可放在任意时机使用（比如工具栏按钮点击），前提是确保 cache 已就绪。若不确定是否加载完成，加个守卫：
- 在
done回调里直接用，最稳 - 在按钮 handler 中，先检查
cache && cache.length，为false则提示“请稍候，数据加载中” - 别用
table.getData('myTable')替代 —— 它返回的是当前可见行（含搜索/筛选结果），不是当前页原始切片
为什么不能用 LAY_TABLE_INDEX 或 DOM 顺序
d.LAY_TABLE_INDEX 是全局递增序号，不随分页重置；而 DOM 的 tr 顺序在开启排序、筛选或服务端分页后，完全脱离原始数据顺序。例如你点了“按时间倒序”，界面上第一行实际对应 cache[17]，此时用 $('tbody tr').first().data('index') 拿到的下标毫无意义。
更危险的是：Layui 不保证 tr 元素上挂载的 data-index 始终与 table.cache 下标一致，尤其在 reload 或动态列变更后，容易错位。
- 唯一能对齐的参照系只有
table.cache['id']数组本身 - 如果需要带序号的展示（如“第 1 条”），应在
templet里用(curr - 1) * limit + d.LAY_TABLE_INDEX + 1计算，而非反向从 DOM 推数据
注意 reload 后的缓存时效性
每次 table.reload() 都会清空旧 cache 并触发新的请求，新数据写入 table.cache['id'] 是异步的。如果你在 reload 调用后立刻读 cache，大概率拿到的是旧值或空值。
正确做法是：把取首尾数据的逻辑放在 done 回调里，或监听 table.on('done(id)', ...) 事件。不要试图在 reload 的 success 回调里读 —— Layui 的 reload 没有 success 钩子，它的异步完成信号只有 done。
这个点最容易被忽略：你以为 reload 完了就能读，其实 cache 还没刷进来。
