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 进来、按空格/回车唤起文件选择框。两者缺一不可：
立即学习“前端免费学习笔记（深入）”；
- 用
<div draggable="false" tabindex="0">，别套 <code><button></button>或<label></label>——它们自带点击逻辑，和drop冲突 - 禁用
contenteditable="true"，Safari 下会吞掉整个drop事件 - 加上
role="region"和aria-label="上传文件区域"，否则屏幕阅读器无法识别功能意图 - 用
if ('ontouchstart' in window || navigator.maxTouchPoints > 0)判断触屏设备 - 降级为隐藏
<input type="file">+ 点击触发，样式覆盖成“拖拽区”外观 - 不模拟 touch-to-drag，移动端手指滑动距离和速度难控，极易误触
- 若业务强依赖拖拽（如设计稿批量上传），明确提示“请在桌面端操作”比强行兼容更可靠
-
iframe场景：监听代码写在iframe.contentWindow上，不是父页面window - Shadow DOM 场景：确保区域在
open模式下，并把dragover/drop绑定到shadowRoot内部节点 - 移动端 Safari 对 Shadow DOM + 拖拽支持极差，基本不可用，别在这上面浪费时间
移动端必须降级，别硬撑原生拖拽
iOS Safari 直到 16.4 才提供有限的 dataTransfer.files 支持，且仅限部分机型；Android WebView 表现更碎片化。试图在移动端监听 drop 基本等于写无效代码。
真实可行的方案是检测环境后主动降级：
跨 iframe 或 Shadow DOM 必须各自绑定事件
拖拽事件不会自动穿透边界。目标区域在 iframe 里？主页面绑的 dragover 完全收不到；在 Shadow DOM（尤其是 closed 模式）中？事件根本冒泡不出来。
必须分别处理：
真正落地时最麻烦的永远不是“怎么拖”，而是“什么时候不该拖”——空 type、文件夹、跨边界、权限限制、移动端兼容。边界情况不提前想清楚，上线后第一波用户反馈就是“拖不进去”。
