initSort 必须显式配置为 {field: 'xxx', type: 'asc' | 'desc'} 对象，字段名和 type 值需严格匹配，仅对 sort: true 的单列生效；服务端分页下它仅作初始视觉提示，真正排序需在 sort 事件中通过 reload 向后端传递参数。
initSort 必须显式配置，否则不生效
表格加载时默认不排序，initsort 不是可选参数，而是必须写的完整对象。写成 null、undefined、字符串或漏掉 type 都会静默失效。
-
initSort必须是{field: 'xxx', type: 'asc' | 'desc'}格式，字段名大小写、下划线必须和列定义中的field完全一致 -
type只接受"asc"或"desc"，写成"ascending"、"up"等无效 - 它只对
sort: true的列起作用，且仅支持单字段——多字段初始排序需手动拼where并首次reload - 若用
data数组传数据，initSort会立即执行前端排序；若用url加载，则只在done回调后对已加载数据重排
服务端分页下 initSort 看似无效？先看后端是否已排序
最常踩的坑：开了 page: true，后端 SQL 里写了 ORDER BY，Layui 默认信任后端顺序，不会二次前端排序——此时 initSort 看起来没效果。
- 检查 Network 面板，确认接口返回的数据是原始未排序顺序（比如 ID 乱序）
- 要么关掉后端
ORDER BY，让 Layui 全权处理排序逻辑 - 要么设置
autoSort: false，并在done里手动调用table.sort('field', 'desc') - 注意：
table.sort()不发请求，只重排当前内存数据；服务端分页时，后续翻页仍按后端返回顺序，不受影响
点击表头后 initSort 状态丢失是正常行为
Layui 认为用户手动触发过排序，就以用户操作为准，不再回退到初始状态。这不是 bug，是设计逻辑。
- 想每次刷新都重置回默认排序，得在
done回调中记录初始状态，并监听sort事件做干预 - 例如：首次进入时
table.sort('score', 'desc')，之后用户点其他列再点回来，不自动恢复 - 监听时别直接无条件调用
table.sort()，容易死循环；建议加标志位或判断obj.field !== 'score'再重置 -
initSort和sort事件本质是两套逻辑——前者只跑一次，后者接管所有后续交互；混用时务必分清数据来源（前端内存 or 后端响应）和分页开关状态
要走服务端排序，initSort 只是起点，关键在 sort 事件里 reload
initSort 本身不触发后台请求，它只是前端初始化状态。真要服务端排序，必须关闭前端自动排序，并在 sort 事件中手动 reload。
- 必须设
autoSort: false，否则点击表头仍执行前端排序，掩盖后台行为 - 监听
table.on('sort(demo)', function(obj){...})，拿到obj.field和obj.type -
reload时把排序参数塞进where，如where: { sortField: obj.field, sortOrder: obj.type } - 后端必须校验字段白名单，不能直接拼 SQL——
obj.field是用户可控输入，不做过滤会引发 SQL 注入 - 多字段排序需自行维护栈结构，拼成
sort=age:desc,name:asc这类格式，后端解析后严格按顺序生成ORDER BY
initSort 在服务端分页场景下，几乎只起“视觉提示”作用——它不发请求、不改后端行为、不保证后续翻页顺序。是否生效，最终取决于你有没有在 sort 事件里把排序意图正确传递给后端，以及后端是否真按这个意图执行了数据库排序。 
