table.reload() 必须传入 where 对象，且只认顶层 where 字段；reload 时需同时指定 url、where（动态构建、过滤空值）、page: { curr: 1 }，并显式传递自定义 request 函数，id 必须与初始化时完全一致。
table.reload() 必须传 where 对象，其他写法全无效
你点搜索按钮后调 table.reload('id', { keyword: 'abc' })，接口根本收不到 keyword。Layui 只认 where 这个顶层字段，且它必须是对象。任何把参数塞到 data、params 或直接平铺在配置对象里的写法，都会被忽略。
常见错误包括：
- 写成
table.reload('id', { search: 'abc' })→ 后端收不到 - 写成
table.reload('id', { where: 'abc' })（字符串）→ 控制台报错或静默失败 - 写成
table.reload('id', { where: null })→ 仍沿用上次缓存的where
正确姿势只有一种：table.reload('id', { where: { keyword: 'abc', status: 'pending' } })。注意：空字符串、undefined、null 值别往里塞，后端容易误判。
换 URL 时 where 不清空，旧条件会偷偷发出去
比如你从「全部订单」切到「待发货订单」，新接口是 /api/orders/pending，但没重置 where，表格仍带着上一次的 { keyword: 'test' } 去请求，结果查出来是空——因为新接口根本不支持 keyword 参数。
解决方案是每次 reload 都显式构造干净的 where：
- 下拉选“全部”时，对应值设为
''或null，然后过滤掉所有 falsy 值 - 日期范围控件返回
"2026-09-01"，但后端要"2026/09/01"，得先格式化再进where - 手动拼接 URL 查询串（如
?status=pending）是自找麻烦，交给where让 Layui 自动处理更稳
page.curr 不重置，翻页逻辑就乱了
用户在第 5 页搜关键词，你 reload 时只传了新 url 和 where，但没传 page: { curr: 1 }，表格会继续从第 5 页发起请求。而新接口很可能只有 2 页数据，结果就是空白页 + 无报错。
只要涉及搜索或筛选，reload 必须带三样：
url: '/new/api'-
where: { ... }（动态构建，不含空值） -
page: { curr: 1 }（强制回到第一页）
漏掉 page，哪怕 where 写对了，体验也断层。
用了自定义 request，reload 时必须一并传入
如果你在初始化时写了 request: function(obj) { ... } 来加 token 或时间戳，那每次 table.reload() 都得把这个函数原样带上。否则 Layui 会退回到默认请求逻辑，token 就丢了，401 报错随之而来。
典型写法：
table.reload('userTable', {
url: '/api/users',
where: { dept_id: 101 },
page: { curr: 1 },
request: myCustomRequest // 必须显式传，不能指望它自动继承
});
这个 myCustomRequest 函数里，obj.where 已经是 reload 传进来的最新值，你只需在此基础上追加字段，不用重复 merge。
最易被忽略的一点：reload 的 id 必须和 table.render() 初始化时的容器 ID 或 elem 选择器完全一致，大小写、前后空格、#号缺一不可——输错一个字符，整个 reload 就静默失效，控制台还不报错。
