应根据业务场景选择：需重绘整个表格（如改列、换接口）用 table.reload()；仅更新数据且不改结构用性能更好、可固定滚动位置的 table.reloadData()。
table.reload() 和 table.reloadData() 到底该用哪个
看业务场景：要重绘整个表格（比如改了列、换接口、调高高度），用 table.reload()；只换数据、不改结构，用 table.reloaddata()。后者性能更好，滚动位置也能靠 scrollpos: 'fixed' 锁住，但前者能覆盖更多配置变更。
常见错误是混用——比如表头字段没变，却调 table.reload()，结果触发全量重渲染，页面闪一下，用户正在看的那页还被强制跳回第一页。
-
table.reload('id', { where: { status: 1 } })→ 适合搜索、筛选、分页跳转等“带条件刷新”场景 -
table.reloadData('id', { scrollPos: 'fixed' })→ 适合后台主动推送新数据、定时轮询、编辑后局部刷新 - 两者都支持
where，但table.reloadData()不会重置page.curr，而table.reload()默认会回到第一页（除非显式传page: { curr: 2 }）
where 参数写错导致后台收不到值
很多人写 where: { id: 123 }，结果后端拿到的是空对象或报错。原因在于：Layui 的 where 是“透传层”，它会把整个对象序列化成 query string 或 request body 字段，但某些后端框架（如 Spring Boot）默认只解析一级 key，不支持嵌套对象。
官方示例里写 where: { key: { id: demoReload.val() } }，不是为了炫技，而是为适配后端约定的接收结构（比如后端 expect key.id）。你得跟后端对齐字段路径。
- 前端传
where: { user_id: 123 }→ 后端收request.getParameter("user_id") - 前端传
where: { filter: { type: 'vip', page: 2 } }→ 后端需按 JSON body 解析，或约定好用@RequestBody Map<string object></string> - 别在
where里塞page或limit，Layui 会自动加，重复传会导致分页错乱
reload 后数据没更新？先查这三件事
不是代码没跑，是常卡在“你以为 reload 了，其实没真正发请求”这个环节。
- 检查
url是否为空：如果table.render()时没设url，table.reload()也不会发请求，只会用本地缓存（table.cache['id']）重新渲染 - 看 Network 面板有没有新请求：没请求 = 没走异步流程；有请求但返回旧数据 = 后端没读
where参数，或缓存没清（比如加了时间戳参数防缓存：url: '/api/list?t=' + Date.now()） - 确认 ID 对不对：
table.reload('wrongId', {...})不报错也不生效，Layui 会静默忽略不存在的实例 ID
想清空表格再填新数据，别用 reload
直接 table.reload({ data: [] }) 再 table.reload({ data: newData })，看起来顺，实则危险：两次 reload 之间如果用户点了排序或分页，状态就乱了。更稳的做法是“一次到位”。
如果新数据已存在前端（比如从 WebSocket 收到、或本地计算得出），直接用 data 字段一次性替换：
table.reload('myTable', {
data: myNewDataList,
page: { curr: 1 }
});
注意：myNewDataList 必须是数组，且每项要有唯一 id 字段（哪怕后端没给，也得自己补上，否则树表、复选框、行点击事件都会出问题）。
最易被忽略的点：reload 后，table.cache 不会自动同步新数据 —— 它只在首次 render 或服务端返回时更新。如果你后续还要操作缓存（比如查某行是否存在），得手动赋值：layui.table.cache['myTable'] = myNewDataList。
