table.reloadData()默认不保留当前页码，因其为轻量刷新，仅覆盖data、where等有限字段，page不在继承列表中，需手动传入page: { curr: n }才能维持当前页。
table.reloadData() 为什么默认不保留当前页码
因为 reloaddata 是轻量级数据刷新，只覆盖 data、where、scrollpos 等有限字段，page 不在默认继承列表里。它不走完整初始化流程，所以不会读取或维持 table.config[id].page.curr——这个值得你亲手塞进去。
常见错误现象：
- 调用
table.reloadData('userTable', { data: newData })后，表格跳回第一页 - 控制台没报错，Network 里请求正常，但分页栏显示“1”
正确做法是显式传入 page: { curr: n }：
- 先从配置里取当前页：
const curr = table.config['userTable']?.page?.curr || 1 - 再透传：
table.reloadData('userTable', { data: newData, page: { curr } }) - 注意：必须是对象
{ curr: n }，不能只写curr: n，否则无效
什么时候该用 table.reload() 而不是 reloadData
reload 会重建整个表格实例，包括列定义、工具栏、事件绑定、高度、分页配置等；reloadData 只动数据和少数几个参数（如 scrollPos、where）。
适用场景判断：
- 改了
cols、加了新工具栏按钮、切换了url或启用了tree模式 → 必须用table.reload() - 仅更新数据、筛选条件变化、后台推送新记录 → 优先用
table.reloadData()，性能更好、滚动位置可锁住 - 想重置到第一页并清空所有状态（比如退出搜索态）→
table.reload()+page: { curr: 1 }
容易踩的坑：
- 误用
reload刷新纯数据：会导致事件重复绑定（点击行弹两次窗）、自定义done回调里的闭包变量失效 - 漏传
page给reload：它默认回到第一页，但很多人以为会“继承”，结果用户正在看第 5 页，一刷就回顶了
where 参数传错导致后端收不到查询条件
where 是透传字段，Layui 不做结构校验，直接序列化进 URL query 或 request body。后端能否收到，完全取决于你传的结构是否匹配其接收约定。
典型错误：
- 前端写
where: { id: 123 }，后端用@RequestParam("id")接，没问题 - 前端写
where: { filter: { type: 'vip' } }，后端却仍用@RequestParam，那filter整个对象就丢了 - 在
where里手动写page或limit：Layui 分页逻辑会自动加，重复传会导致后端解析错乱
建议做法：
- 跟后端对齐字段层级：如果后端要求
params.filter.status，前端就传where: { filter: { status: 'active' } } - 不确定时，打开浏览器 Network 面板，看实际发出的请求 URL 或 payload 长什么样
- 调试阶段加时间戳防缓存：
url: '/api/list?t=' + Date.now()
reloadData 的 scrollPos 和 expandStatus 怎么用才不翻车
这两个参数专为用户体验优化，但用错反而更糟。
scrollPos: 'fixed'：
- 作用：保持滚动条位置不变，避免大数据表刷新后“闪回顶部”
- 注意：只在有真实滚动条时生效；若表格高度未设或内容不足一屏，该参数无效果
expandStatus: true（treeTable 场景）：
- 作用：保留节点展开/折叠状态
- 前提：数据中每个节点必须有稳定、唯一的
id字段，且tree.customName.id配置正确 - 翻车点：如果新数据里节点
id生成逻辑变了（比如后端返回的是临时 UUID），expandStatus就会失效甚至错乱
复杂点在于：这些状态不是“自动同步”的，而是靠前后数据 id 字段严格匹配来映射。一旦 ID 对不上，哪怕只差一个字符，Layui 就当它是全新节点处理。
