Sortable.js是唯一靠谱的选择，因其能真实监听DOM位置变化、支持移动端fallback，且兼容性最好；必须等所有上传完成再初始化，el指向预览容器本身，移动端启用forceFallback，onEnd中通过维护的uploadedFiles数组和fileOrder隐藏域同步顺序。
直接操作 DOM 无法保证上传顺序，因为 layui.upload 的 done 回调只按响应时间拼接结果，不维护原始文件索引；拖拽视觉顺序和后端接收顺序必然脱节。必须用外部排序库接管预览容器，并显式同步顺序到隐藏域。
为什么 Sortable.js 是唯一靠谱的选择
Layui 自身不提供拖拽排序能力，index 参数在 done 中仅表示「当前上传在原始队列里的位置」，不是「最终列表序号」；并发上传下响应时间不可控，index 完全失效。而 Sortable.js 能真实监听 DOM 位置变化，且支持移动端 fallback，是目前最轻量、兼容性最好的方案。
- 必须等所有
done执行完毕、<img>真实插入到.layui-upload-list后再初始化Sortable，否则找不到目标元素 -
el必须指向预览容器本身（如document.getElementById('demo2')），不能是子元素或 jQuery 包装对象 - 移动端务必加
forceFallback: true，否则 iOS Safari 不触发dragstart -
animation: 150必须设，否则拖拽反馈卡顿，用户感知差
如何正确绑定 onEnd 并写回顺序
onEnd 是唯一可靠的回调时机，它提供 evt.oldIndex 和 evt.newIndex，但注意：这两个值是针对当前 .layui-upload-list > li 或 > img 的实时 DOM 顺序，不是原始文件数组下标——你得自己维护一个映射数组。
- 在
before阶段用obj.preview()预读时，把file对象 push 到全局数组（如uploadedFiles = []） -
done中只负责插入 DOM，不修改数组；onEnd中用evt.oldIndex/evt.newIndex在uploadedFiles上做 splice 移动 - 移动后立刻更新隐藏域：
$('input[name="fileOrder"]').val(uploadedFiles.map((_, i) => i).join(',')) - 如果预览区混有 loading 占位图（比如上传中状态），
Sortable会把它一起拖——建议只在done后 append 成功项，避免干扰
预览容器样式和后端接收的关键细节
Sortable 默认不提供插入占位符，而 .layui-upload-list 也没预留空间，拖拽时用户根本看不出松手后插在哪。后端若不按前端传的顺序处理，整个排序就白做了。
-
.layui-upload-list必须加position: relative，否则ghostClass定位偏移 - CSS 中定义
.sortable-ghost { opacity: .6; }和.sortable-chosen { transform: scale(1.02); }提供基础反馈 - 后端绝不能依赖请求到达顺序或文件名排序；唯一可靠依据是前端传来的
fileOrder字段（如"2,0,3,1"），它对应原始文件数组下标 - PHP 框架要遍历
$_FILES['file']['name']数组，不能只取[0]；Node.js + multer 必须用upload.array('file')；Spring Boot 用MultipartFile[]
最容易被忽略的是：框架中间件（如 Laravel、ThinkPHP）默认把多文件当独立请求处理，不会保留原始选择顺序。必须显式读取 fileOrder 字段并重排文件数组，否则拖拽完还是老样子。
