dragover中只执行e.preventDefault()和视觉反馈，校验和读取操作必须延至drop回调；目标区域需设draggable="false"和tabindex="0"；移动端应降级为file input；跨iframe或Shadow DOM需分别绑定事件。

dragover里别做校验和读取操作

高频触发的 dragover 事件不是做文件类型判断或 FileReader 预读的地方。它每秒可能触发几十次，一写 file.name.includes(".pdf") 或 file.slice(0, 4).arrayBuffer() 就卡顿，光标拖拽变“粘滞”，用户松手前就已误判区域。

正确做法是只在 drop 回调里集中处理：

• dragover 中只做 e.preventDefault() 和视觉反馈（如加 class="drag-over"）
• drop 中再用 Array.from(e.dataTransfer.files) 拿文件列表
• 校验用 file.name 后缀 + file.type 双保险，不依赖单一项
• 失败时直接 return，不 alert、不弹框，避免中断拖放流

目标区域必须加 draggable="false" 和 tabindex="0"

没这两个属性，区域本身会“参与拖拽源”，导致鼠标划过内部文字时触发系统级文本拖拽，松手瞬间就复制了一段文字而不是上传文件——这不是 bug，是浏览器默认行为。

draggable="false" 显式声明：“我不发起拖拽，但我可以接收”；tabindex="0" 让键盘用户能 Tab 进来、按空格/回车唤起文件选择框。两者缺一不可：

• 用
  ，别套 或 ——它们自带点击逻辑，和 drop 冲突
• 禁用 contenteditable="true"，Safari 下会吞掉整个 drop 事件
• 加上 role="region" 和 aria-label="上传文件区域"，否则屏幕阅读器无法识别功能意图

移动端必须降级，别硬撑原生拖拽

iOS Safari 直到 16.4 才提供有限的 dataTransfer.files 支持，且仅限部分机型；Android WebView 表现更碎片化。试图在移动端监听 drop 基本等于写无效代码。


使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审
使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。
下载

真实可行的方案是检测环境后主动降级：

• 用 if ('ontouchstart' in window || navigator.maxTouchPoints > 0) 判断触屏设备
• 降级为隐藏 + 点击触发，样式覆盖成“拖拽区”外观
• 不模拟 touch-to-drag，移动端手指滑动距离和速度难控，极易误触
• 若业务强依赖拖拽（如设计稿批量上传），明确提示“请在桌面端操作”比强行兼容更可靠

跨 iframe 或 Shadow DOM 必须各自绑定事件

拖拽事件不会自动穿透边界。目标区域在 iframe 里？主页面绑的 dragover 完全收不到；在 Shadow DOM（尤其是 closed 模式）中？事件根本冒泡不出来。

必须分别处理：

• iframe 场景：监听代码写在 iframe.contentWindow 上，不是父页面 window
• Shadow DOM 场景：确保区域在 open 模式下，并把 dragover / drop 绑定到 shadowRoot 内部节点
• 移动端 Safari 对 Shadow DOM + 拖拽支持极差，基本不可用，别在这上面浪费时间

真正落地时最麻烦的永远不是“怎么拖”，而是“什么时候不该拖”——空 type、文件夹、跨边界、权限限制、移动端兼容。边界情况不提前想清楚，上线后第一波用户反馈就是“拖不进去”。