table.reload() 排序时需手动合并搜索条件并重置 page.curr 为 1，否则丢失筛选项且分页异常；应实时维护 window.searchWhere 对象，确保 where 参数拼接而非覆盖，并与后端排序字段名严格对齐。
table.reload() 必须传入当前搜索条件
点击表头触发排序时，默认只带 field 和 type 去请求后端，之前填的搜索关键词、下拉筛选项等全丢了。根本原因是 table.on('sort(...)') 里没把已有的 where 条件合并进去。
正确做法是：在监听排序事件时，手动读取当前搜索参数对象（比如你存在 window.currentSearchParams 或用 form.val('search-form') 动态获取），再传给 reload()：
table.on('sort(userTable)', function(obj){
table.reload('userTable', {
initSort: obj,
where: $.extend({}, window.currentSearchParams, {
field: obj.field,
order: obj.type
})
});
});
- 别直接写死
{keyword: $('#keyword').val()}—— 如果用户刚改了状态筛选但还没点搜索，这个值就不是最新状态 - 推荐把所有搜索字段统一收集到一个对象里（如
window.searchWhere），每次输入/选择后实时更新它 -
$.extend或展开运算符{...searchWhere, field: ..., order: ...}都行，关键是“拼”而不是“覆盖”
搜索条件必须在 reload 前已就绪
常见错误是：搜索框用 form.on('submit', ...) 绑定，但排序事件比 submit 更早触发，导致 window.searchWhere 还没更新。
解决方案分两步：
- 所有搜索控件（
<input>、<select></select>、laydate）都加change或keyup监听，实时同步到window.searchWhere - 日期控件注意格式：如果后端要
2024-01-01，而laydate返回的是2024/01/01，得先格式化再存 - 清空搜索框时，对应字段要从
window.searchWhere中delete，不能只设为''—— 否则会传空字符串给后端，可能查出意外数据
page.curr 必须重置为 1
排序 + 搜索叠加时，如果用户在第 5 页搜完再点表头，reload() 默认还在第 5 页发起请求，结果常为空白。
只要条件变了（包括排序字段变化），就必须显式带上分页重置：
table.reload('userTable', {
page: { curr: 1 },
where: { ... }
});
- 不加
page: { curr: 1 }是绝大多数“搜完排序就丢数据”的根源 - 如果你真想保留原页码（极少见），得先读
table.cache['userTable']?.length判断当前页是否有数据，再决定是否跳回第 1 页 —— 但多数业务场景不该这么做 - 性能上，不重置页码会导致反复请求末页，尤其当总条数少于一页容量时，直接返回空数组
initSort 要和 where 字段名对齐
后端接口通常要求排序参数叫 sort_field 和 sort_order，但你传了 field 和 order，后端收不到，排序就失效。
检查点很具体：
- 看接口文档或抓包确认后端实际接收哪两个字段名
-
initSort只控制表头箭头显示，真正起作用的是where里的键名 - 如果后端要
{sort: 'name', dir: 'desc'}，那就得写where: {sort: obj.field, dir: obj.type}，而不是照抄文档示例 - 字段名大小写敏感，
obj.field是小写的name，别手抖写成Name
