必须手动调用table.reload()才能触发请求；默认autosort:true仅前端排序，需设false启用服务端排序；sort事件中用obj.field和obj.type传参，后端须校验字段白名单。
必须手动触发 table.reload()，layui 不会自动发请求——这是最常被误解的一点。
为什么点击表头没发请求？
Layui 默认开启前端排序（autoSort: true），点击只重排内存数据，不走网络。哪怕你配置了 url，只要没关掉前端排序，后端就收不到任何排序参数。
- 检查是否漏写
autoSort: false—— 这是服务端排序的前提 - 确认
table.on('sort(filter)')的 filter 值和table.render()中的id严格一致（大小写、下划线都不能错） - 如果用了静态表格转 Layui（
lay-filter方式），监听事件要换成table.on('sort(*)')，否则可能监听不到
如何在 sort 事件里正确传参给后端？
obj.field 和 obj.type 是唯一可靠来源，但不能直接拼 SQL；后端必须校验字段白名单。
- reload 时用
where: { sortField: obj.field, sortOrder: obj.type }，避免和分页参数（如page、limit）冲突 - 别用
obj.field当 SQL 字段名直拼——后端必须查白名单，比如['name', 'age', 'create_time']，不在列表里就拒绝或默认主键 - 如果后端要求格式是
order=name%20asc,age%20desc，那就手动拼：where: { order: `${obj.field} ${obj.type}` }
后端返回数据没按新顺序渲染？
常见原因不是前端问题，而是后端没真正排序，或前端配置矛盾。
- 确保
page: true已开启——where参数在page: false时会被忽略 - 后端返回的
data数组必须是已按新规则排序后的结果，不是原始未排序全量数据 - 如果 reload 后表头图标没变方向，检查是否漏传
initSort: obj，这个参数只影响 UI 状态，不影响请求
最容易被跳过的是后端字段白名单校验——一旦允许任意 sortField 值进 SQL，攻击者就能传 sortField=id; DROP TABLE user 这类恶意内容。字段名必须映射到预设枚举，不能靠字符串拼接。
