最稳方式是用 event.target.closest('tr') 定位行，避免内联索引和 data-index；更新缓存须整行覆盖而非局部修改；toolbar/templet 列需手动 DOM 操作，updateRow 不生效。
点击按钮后怎么精准定位到它所在的那一行
按钮必须和行建立可靠绑定，不能靠全局索引（比如 tr[0]）或硬编码位置。最稳的方式是用 event.target.closest('tr') 向上找最近的 tr 元素——无论表格有没有分页、是否启用了 scroll 模式，这个 dom 路径都有效。
常见错误是给按钮写 onclick="updateRow(2)" 这类带固定数字的内联调用，一旦新增/删除行，序号就全错。也别依赖 data-index 属性，它只在当前页有效，翻页后失效。
- 确保按钮在
toolbar模板里，或加了唯一 class（如class="update-btn"）便于事件委托 - 用
document.addEventListener('click', ...)统一监听，避免重复绑定 - 拿到
tr后，用$(tr).data('index')或tr.dataset.index可取当前页缓存下标（仅限静态数据模式）
更新 table.cache 时为什么必须整行覆盖而不是局部 merge
Layui 的 table.updateRow() 和视图刷新逻辑，依赖缓存中该行对象的引用一致性。如果只改 cache[i].status = 'done'，后续调用 table.updateRow() 时内部会尝试深拷贝旧对象再合并，容易丢字段或触发不可预期的渲染顺序问题。
尤其当列配置里有 templet 依赖多个字段计算值时（比如状态文案由 status + updated_at 拼接），局部赋值可能导致 templet 函数读到“半新半旧”的数据。
- 正确做法：
cache[i] = $.extend({}, cache[i], { status: 'done', updated_at: new Date().toISOString() }) - 如果用原生 JS，用
cache[i] = { ...cache[i], status: 'done' }（注意字段名大小写必须和原始数据完全一致） - 字段名错一个字母，
table.updateRow()就不会更新对应单元格，也不会报错
调用 table.updateRow() 前必须确认哪些前提条件
table.updateRow() 不是万能的：它只更新已有行的单元格内容，不处理 toolbar 列、不触发 templet 重执行，也不刷新合计行。而且它要求表格初始化时已指定 id 参数（如 id: 'userTable'），否则找不到目标实例。
如果你的列是用 toolbar: '#bar' 渲染的操作栏，或者某列用了 templet 但没配 field，updateRow() 对这些列完全无效——它们的 DOM 是独立生成的，得手动操作 tr 下的对应 td。
- 检查
tableIns.config.id是否存在，不存在就别调updateRow() - 更新前先确认该行在
table.cache[tableName]中存在（可能已被删除或未加载） - 更新 toolbar 列？只能用
$(tr).find('.layui-table-cell:eq(5)').html('新按钮')这类 DOM 操作
带分页的表格点按钮更新后如何不跳回第一页
直接调 table.reload() 必然重置页码为 1，因为它是全新请求。而 table.updateRow() 本身不发请求，但它依赖缓存；如果表格是远程分页（url 配置），table.cache 默认只存当前页数据，翻页后你刚改的那行就没了。
所以真要支持分页场景下的局部更新，你得自己维护一份全量数据副本（比如存在 window.allUserData = []），每次 reload 后同步更新它，按钮点击时从副本里找 ID 修改，再用 table.updateRow() 刷新视图——否则用户翻页再翻回来，数据又变回旧的。
- 远程分页下，
table.cache['xxx']永远只是当前页的快照，不是全量 - 别试图在
done回调里手动改table.cache，Layui 下次reload会把它整个覆盖掉 - 如果业务允许，优先用静态数据模式（
data: [...]）初始化表格，省去大部分状态同步麻烦
updateRow()，直接操作 DOM 或重新渲染整行**。很多人卡在这一步，反复检查 cache 和 updateRow 参数都没问题，却忘了那几个按钮根本不在 field 体系里。
