dragover事件必须阻止默认行为，否则drop不会触发；drop中读取文件应使用e.dataTransfer.files而非e.target.files；跨域拖拽时dataTransfer为空；移动端不支持原生drag/drop文件操作。
dragover 事件必须阻止默认行为，否则 drop 不会触发
HTML5 拖拽文件到页面时，drop 事件根本没执行？大概率是 dragover 没正确处理。浏览器默认会把拖入的文件当作“打开链接”或“导航”，不阻止就直接走了。
实操上，只监听 drop 是不够的；必须给目标区域（比如 div#dropzone）同时绑定 dragover 并调用 e.preventDefault()：
dropzone.addEventListener('dragover', e => {
e.preventDefault(); // 关键：没这句，drop 永远不会来
});
- 仅
preventDefault()就够了，不需要e.stopPropagation() - 不能只在
drop里阻止——那时已经晚了，dragover阶段就决定是否允许投放 - 如果用了 CSS
pointer-events: none，也会让 drag 事件失效，需检查
drop 事件中读取文件要用 e.dataTransfer.files，不是 e.target.files
拿到 drop 事件后，很多人下意识去查 e.target.files，但那是 <input type="file"> 的属性，drag 场景下完全无效。
真实文件列表藏在 e.dataTransfer.files 里，它是个 FileList 对象，类似数组但不可遍历用 for...of 需转成数组：
立即学习“前端免费学习笔记（深入）”；
dropzone.addEventListener('drop', e => {
e.preventDefault();
const files = Array.from(e.dataTransfer.files); // 转成真数组才好 map/filter
files.forEach(file => {
console.log(file.name, file.size, file.type);
});
});
-
e.dataTransfer.items也能取文件，但兼容性差（Safari 旧版不支持），优先用files - 如果拖的是文件夹，
files里**不会包含子文件**（除非显式启用webkitdirectory，但那是 input 场景） - 注意：
e.dataTransfer.files是只读的，不能 push 或 splice
跨 iframe 或跨域拖拽时 dataTransfer 为空
把文件从桌面拖进 iframe 里的页面？或者从另一个域名的页面拖进来？那 e.dataTransfer.files 很可能为空，甚至整个 dataTransfer 是 null。
这是浏览器安全限制：跨源拖拽时，为防信息泄露，dataTransfer 会被清空（Chrome/Firefox 均如此）。没有绕过办法，只能接受限制。
- 同源 iframe 内拖拽正常，但父页和子页协议、域名、端口任一不同，即算跨源
- 桌面 → 页面 是同源的，不受影响；但页面 A → 页面 B（不同域）一定失败
- 别试图用
e.dataTransfer.getData('Files')，这个 API 已废弃且基本不返回内容
移动端不支持原生 drag/drop 文件操作
别在 iOS 或 Android 上指望 dragstart/drop 能接住用户从文件管理器拖进来的文件——它们压根不触发这些事件。
移动端唯一可靠路径是 <input type="file" multiple>，配合 accept 和样式隐藏，做成“点击上传”按钮。哪怕你用 touchstart 模拟拖拽，也无法访问本地文件系统。
- iOS Safari 16.4+ 开始支持
input[type=file]选择文件夹（webkitdirectory），但依然不是 drag/drop - 某些 PWA 可通过 File System Access API 读写，但需要用户主动授权，且非所有安卓浏览器支持
- 所谓“移动端拖拽上传”宣传，背后基本都是降级到 input + 自定义 UI
dragover 必须 preventDefault，以及误以为移动端能走同一套逻辑。 
