table.updateRow()是最稳的行级更新方案，官方自2.7+支持，不依赖事件上下文，精准刷新单元格并同步分页排序状态；需确保表格有id、用唯一字段定位、field名严格匹配，templet/toolbar需额外处理。
用 table.updateRow() 是最稳的方案
2.7+ 版本起，table.updateRow() 是官方明确支持的行级更新方式，不依赖事件上下文，也不需要手动操作 DOM 或缓存。它能精准定位并刷新对应单元格内容，且自动同步分页、排序状态。
常见错误是误用 obj.update()（仅限 tool 事件回调内可用）或直接改 table.cache 后不触发视图更新——前者调用范围受限，后者容易漏掉重绘逻辑。
- 必须确保表格初始化时设了
id: 'userTable'，否则table.updateRow('userTable', ...)找不到实例 - 定位方式优先用服务端返回的唯一 ID（如
user_id），而非索引：避免翻页后错位 - 字段名必须和列配置中的
field完全一致（大小写、下划线都不能错），否则静默失败 - 如果列用了
templet或toolbar，updateRow()不会重绘这些区域，需额外处理
没 ID 字段或用老版本？得手动同步 table.cache + DOM
当表格没传 id 字段、或还在用 2.6 及更早版本时，table.updateRow() 无法使用。此时必须自己维护缓存与视图的一致性——只改 table.cache 不更新 DOM，或只改 DOM 不更新缓存，都会导致后续翻页/排序出错。
关键点不是“怎么改”，而是“改完怎么让表格知道”。不能只做一半。
- 先通过
table.cache['userTable']找到目标行（推荐用user_id匹配，别依赖index） - 整行覆盖更新：
cache[i] = $.extend({}, cache[i], { status: 'done' })，不要只写cache[i].status = 'done' - 再用
$(tr).find('td[data-field="status"]').text('done')更新对应单元格文本 - 最后触发一次
layui.event.call(this, 'table', 'cell(userTable)', { tr, td, field: 'status', value: 'done' })（可选，用于通知监听器）
updateCell() 看似简单，但坑最多
layui.table.updateCell() 名字直观，但实际限制极多：它默认只认 data.id 做匹配键，如果你的数据主键是 user_id 却没在 table.render() 里声明 keyType: 'user_id'，调用就完全无效，控制台还不报错。
另一个常被忽略的问题是：它只更新单元格文本，不触发 templet 重执行、不刷新工具栏按钮状态、也不影响合计行。看起来改了，其实很多地方还是旧值。
- 必须在初始化表格时显式配置
keyType，否则按id查找不到目标行 - 如果列配置里写了
templet，updateCell()对该列无效 - 它不改变
table.cache中的原始数据，只是改 DOM，后续 reload 会丢掉修改 - 移动端点击可能失效，因底层依赖双击事件，而 iOS/安卓 WebView 常把双击识别为缩放
编辑后数据没保存？别以为改完就结束了
Layui 的所有行/单元格更新操作，都只作用于前端缓存和视图，不会自动同步到后端。你看到“已审核”变绿了，不代表数据库真改了。
最容易漏掉的是：没在 table.on('edit(filter)', callback) 或按钮点击回调里主动发请求。尤其当用户编辑后直接关页、切 Tab、或点了其他操作按钮，变更就彻底丢失。
- 如果是
edit: 'text'列，监听edit事件是最自然的保存入口 - 如果是工具栏按钮触发的更新，保存逻辑必须放在按钮事件处理函数里，而不是
updateRow()调用之后就不管了 - 服务端返回成功后，建议再调一次
updateRow()把响应数据写回，避免本地缓存和服务器状态不一致 - 字段为空、null、字符串 "0" 或数字 0 都可能导致接口校验失败，前端最好提前做类型归一化
