draggable="false"不能阻止文件拖入，因其仅禁用元素作为拖拽源，不影响接收拖放；真正禁用需在dragover和dragenter中调用preventDefault()阻断默认行为。

为什么给区域加 draggable="false" 不能阻止文件拖入

因为 draggable="false" 只控制该元素是否能作为「拖拽源」，对「接收拖拽」完全无效。浏览器默认允许任何元素接收文件拖放（只要没显式拦截），所以即使你把 draggable="false" 加在 <div> 上，用户照样能把文件拖进这个区域并触发 <code>drop —— 这是浏览器原生行为，不是 bug。

dragover 不调 preventDefault() 就等于没禁

要真正禁用拖入，关键不在“不让它进来”，而在于“让它进不来”。浏览器对 drop 事件有强保护：除非在 dragover（和 dragenter）中调用 e.preventDefault()，否则 drop 根本不会触发，系统会直接执行默认行为（比如打开图片、导航到文件路径）。反过来，如果你主动在这些事件里 preventDefault()，就能彻底阻断整个拖放流程。

• 必须同时监听 dragover 和 dragenter，Safari 对 dragenter 更敏感，只绑 dragover 可能漏掉首次进入
• 不要绑定到 document 或 body 全局——会影响页面其他合法拖拽区域（如上传区）
• 推荐精确绑定到目标容器：document.getElementById('no-drop-area').addEventListener('dragover', e => e.preventDefault())
• 如果区域是动态渲染的（如 React/Vue），确保事件监听器在 DOM 插入后立即挂载，避免监听空节点

禁用拖入时容易忽略的两个副作用

直接在 dragover 里 preventDefault() 虽然有效，但会带来两个隐性问题：

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

• 光标变成“禁止”符号（圆圈斜杠）—— 用户看到的是明确拒绝态，体验生硬；若想静默处理，可额外加 e.dataTransfer.dropEffect = 'none'
• 移动端 Safari 完全不触发 dragenter/dragover，所以纯 JS 方案在此失效；必须配合 CSS 层防御，比如对区域设 pointer-events: none（但注意这也会禁点击）或用 user-drag: none 配合 -webkit-user-drag: none 降低误触概率
• 如果该区域本身是 contenteditable="true" 或含 input/textarea，Safari 会吞掉 drop 事件，此时更稳妥的做法是移除这些属性，或改用 input[type="file"] 显式控件替代

如何与页面其他拖拽功能共存

一个常见陷阱是：全局禁用导致上传区也失效。正确做法是「白名单优先」，而非「黑名单拦截」：

立即学习“前端免费学习笔记（深入）”；

• 给所有合法拖拽目标（如上传区）加特定 class，例如 class="dropzone"，只对非该 class 的容器监听并 preventDefault()
• 避免用 oncontextmenu="return false" 或 ondrop="return false" 写在 HTML 属性里——这类内联事件无法条件化，且难以维护
• 如果使用框架（如 Vue），别依赖 v-on:dragover.prevent 单一修饰符，它不自动覆盖 dragenter；应手写两个事件监听，或封装成指令统一处理
• 测试时务必覆盖 Safari（尤其 iOS）、Edge 和旧版 Chrome，它们对事件触发时机和默认行为的处理差异最大

实际生效的关键不在“怎么写”，而在“在哪写”和“写几处”——漏掉 dragenter、绑错父级、或没考虑移动端 fallback，都会让禁用形同虚设。