必须在 dragover 和 drop 事件中均调用 event.preventDefault() 才能中止默认文件上传行为，仅阻止 drop 不够，因 dragover 未阻止会导致浏览器拒绝接受拖入且 drop 不触发。
拖拽过程中如何中止默认的文件上传行为
浏览器对 dragover 和 drop 事件有默认处理逻辑：不阻止它，就会触发页面跳转（比如拖一个本地 HTML 文件进来直接打开），或在某些场景下静默尝试解析/加载。要“取消正在进行的拖拽操作”，本质是阻止浏览器执行这些默认动作。
关键不是“取消拖拽”本身（拖拽手势由用户发起，无法从 JS 中途强制中断鼠标状态），而是让浏览器忽略这次拖放——这靠在事件处理器里调用 event.preventDefault() 实现。
-
dragover事件必须阻止，默认行为会拒绝接受拖入，导致drop根本不触发 -
drop事件也必须阻止，默认行为可能导航到文件 URL 或尝试渲染 - 仅阻止
drop不够：如果dragover没被阻止，浏览器会显示“禁止”图标，用户松手后事件甚至不会到达drop
为什么只监听 drop 事件无法真正“取消”拖拽
常见误区是只在 drop 里 preventDefault()，以为这样就能拦截。但此时拖拽视觉反馈早已失败——用户拖着文件经过元素时，光标变成圆圈加斜杠，说明浏览器根本没把该区域识别为可投放目标。
这是因为：dragover 的默认行为是“不接受投放”，必须显式阻止才能开启投放通道。没有这一步，drop 事件压根不会派发。
立即学习“前端免费学习笔记（深入）”；
从零开始创建惊艳、动画丰富且自包含的 HTML 演示文稿，或通过转换 PowerPoint 文件生成。当用户希望制作幻灯片、构建演示文稿、打造路演资料（pitch deck）、将 PPT/PPTX 转换为网页格式，或增强现有 HTML 演示文稿时，应使用此能力。该能力帮助用户通过视觉预览而非抽象选项来发掘自身审美偏好。
- Chrome/Firefox/Safari 均要求
dragover中调用preventDefault()才允许后续drop - 即使你只想“取消”而不做任何事，也要写空的
dragover处理器并阻止默认行为 - 别漏掉
dragenter：虽然非必需，但在某些旧版 Safari 中，不处理它可能导致dragleave行为异常
实际代码怎么写才可靠
最简可用模式如下，适用于需要完全禁用拖拽上传、又不想干扰其他交互的场景：
const dropZone = document.getElementById('my-drop-area');
dropZone.addEventListener('dragover', (e) => {
e.preventDefault(); // 必须！否则 drop 不会触发
});
dropZone.addEventListener('drop', (e) => {
e.preventDefault(); // 必须！否则可能跳转或加载文件
// 此处不读取 e.dataTransfer.files，即“取消”后续处理
});
如果还想兼容部分老浏览器或更精细控制，可加上 dragenter 和 dragleave 防止样式错乱：
-
dragenter中preventDefault()并可添加高亮类名 -
dragleave中移除高亮类名（注意：它可能因子元素触发多次，需用relatedTarget判断是否真离开了容器） - 不要在
dragstart或drag里阻止默认行为——它们和文件投放无关，阻止反而可能影响可访问性
容易被忽略的兼容性细节
移动端基本不支持原生文件拖拽（iOS Safari 完全无视 drag* 事件），所以这套逻辑只对桌面端有效。另外几个隐蔽坑点：
- 若元素没有设置
height或内容撑开，dragover可能不触发——因为“可投放区域”实际为 0 高度 - 使用
pointer-events: none的父容器会拦截所有拖拽事件，包括dragover - iframe 内部拖拽需在 iframe 文档内单独绑定事件，跨域 iframe 无法监听其内部拖拽
- 阻止
drop后，e.dataTransfer.files依然存在，只是你不读它——这不是“清除”，而是“放弃使用”
真正要“取消”的，从来不是拖拽动作本身，而是浏览器对它的解释权。给对的事件加对的 preventDefault()，才是可控的起点。
