不可靠。multiple属性仅控制多选功能，不保证拖拽上传时files顺序；实际顺序受操作系统、浏览器版本及事件调度影响，无法依赖索引或默认filelist顺序，须通过显式交互或附加序号字段确保一致性。
拖拽上传时 multiple 的文件顺序是否可靠？
不可靠。浏览器对拖拽进来的文件列表顺序没有统一规范，multiple 本身不保证顺序，实际顺序取决于操作系统、文件管理器、甚至鼠标松开瞬间的底层事件调度。Chrome 在 macOS 上常按 Finder 排序，Windows Edge 可能按资源管理器选中顺序，但同一浏览器不同版本也可能变化。
这意味着：不能假设 event.dataTransfer.files 或 input.files 中的索引对应用户“从左到右”或“按名称排序”的意图。
- 拖拽多个文件时，
files是FileList对象，只读且无sort()方法 -
multiple属性仅控制是否允许多选，不参与顺序定义 - 即使用户按住 Ctrl 逐个点击选择，最终顺序仍由浏览器合成，非 DOM 事件触发顺序
FileList 转数组后能否用 sort() 稳定排序？
可以，但必须基于文件自身属性（如 name、lastModified），不能依赖 index 或 webkitRelativePath（后者在非目录拖拽时为空）。
常见错误是直接 [...input.files].sort() —— 这会按对象引用排序，结果完全随机。
- 安全排序方式：
[...input.files].sort((a, b) => a.name.localeCompare(b.name)) - 若需保留原始拖拽意图（比如用户刻意按时间排列），可尝试
a.lastModified - b.lastModified，但注意精度为毫秒，且部分系统可能截断 -
webkitRelativePath仅在启用directory属性且拖入整个文件夹时有效，普通多文件拖拽中为""
如何让前端上传顺序与用户预期一致？
唯一可控的方式是放弃依赖原生顺序，改用显式交互确认。比如在拖拽后弹出预览卡片，允许用户手动拖动排序，再生成最终上传队列。
如果必须自动处理，建议默认按名称升序，并明确提示用户：“文件将按名称排序上传”。避免静默重排引发困惑。
- 不要监听
dragover中的dataTransfer.items试图提前捕获顺序 —— 它和最终files不一定一致 - 服务端不应假设前端传来的数组顺序有意义；如有强顺序依赖（如视频分片），应在每个文件元数据里加
order字段 - 测试时务必跨浏览器验证：Chrome、Firefox、Edge 在 Windows/macOS 下拖入同一批文件，检查
files[0].name是否一致
移动端 Safari 对 multiple 拖拽的支持现状
不支持。iOS/iPadOS Safari 完全禁用文件拖拽，input[type="file"][multiple] 只能触发原生文件选择器，且一次最多选 1 个文件（即使声明了 multiple）。所谓“拖拽上传”在 Safari 移动端根本不会触发 drop 事件。
这意味着：任何基于拖拽顺序的逻辑，在 iOS 上天然失效，且无法降级模拟。必须单独处理移动端路径，例如强制走点击选择 + 手动排序 UI。
- 检测方式：
!('draggable' in document.createElement('span'))不能准确判断，应直接 UA 检测或用try/catch监听drop - 微信内置浏览器（iOS）同样不支持拖拽，但 Android 微信 WebView 通常支持
- 别指望
input.files在移动端有稳定长度 —— 用户取消选择后，某些版本 Safari 会返回空FileList而非null
实际项目里，顺序问题往往在灰度发布后才暴露——因为开发机和测试机的操作系统、浏览器版本太单一。真要保序，得把排序逻辑下沉到服务端，前端只负责打标记。
