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，是设计逻辑。

深蓝色网站后台管理系统layui框架模板-AdminPro

一款深蓝色网站后台管理系统layui框架模板

下载

• 想每次刷新都重置回默认排序，得在 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 事件里把排序意图正确传递给后端，以及后端是否真按这个意图执行了数据库排序。