drop事件未触发的根本原因是dragover默认被浏览器阻止，必须在dragover回调中调用event.preventDefault()；若遗漏此操作，浏览器将静默拦截drop流程，且不报错、不警告。
拖拽进入时为什么 drop 事件没触发？
常见原因是没阻止 dragover 的默认行为——浏览器默认禁止在非可拖放区域释放文件。只监听 drop 是不够的，必须在 dragover 回调里显式调用 e.preventDefault()，否则 drop 根本不会触发。
- 仅给容器加
ondrop属性或监听drop事件，但没处理dragover→ 上传完全无响应 -
dragover中只写e.stopPropagation()不够，必须e.preventDefault() - 如果编辑器是富文本区域（如
contenteditable），还要注意：某些浏览器对contenteditable元素的dragover行为更严格，建议把拖拽监听绑定到外层容器而非编辑区本身
如何从 DataTransfer 提取真实文件而不是链接或文本？
DataTransfer 对象的 files 属性只在用户拖入本地文件时有值；若拖的是网页图片、URL 或纯文本，files.length === 0，此时得 fallback 到 items 或 getData()。
- 优先检查
e.dataTransfer.files：有文件就直接用，支持多文件批量上传 - 若为空，遍历
e.dataTransfer.items，用item.kind === 'file'过滤出真实文件项，再调用item.getAsFile() - 拖入图片 URL 时，
items里可能有kind: 'string'+type: 'text/plain'，需用item.getAsString()提取 URL，再fetch下载 - 避免直接读
e.dataTransfer.getData('Text')，它可能返回选中文本而非拖入源内容
DataTransfer 在移动端和 Safari 上有哪些兼容性坑？
Safari（尤其 iOS）对 DataTransfer 支持有限：不支持 items API，files 在部分场景下为空，且无法通过拖拽上传文件（iOS 浏览器根本不允许文件拖入网页）。这意味着拖拽上传本质上是桌面端特性。
- 不要依赖
DataTransfer.items在 Safari 中工作，iOS Safari 完全忽略它 - 检测
'draggable' in document.createElement('span')只能判断拖放 API 是否存在，不能代表文件拖拽可用 - 真正可靠的降级方案是：桌面端启用拖拽，移动端隐藏拖拽提示，改用
<input type="file">触发原生选择器 - Chrome for Android 支持拖拽，但仅限从文件管理器拖入；微信内置浏览器等 WebView 环境基本不支持，需明确 UA 检测并禁用相关交互
怎么避免拖拽过程中误触编辑器光标跳转或内容替换？
在 contenteditable 区域内拖拽时，浏览器可能自动插入占位符文本或把文件当作 HTML 片段粘贴进来，干扰编辑逻辑。关键是在拖拽全程抑制编辑器的默认插入行为。
立即学习“前端免费学习笔记（深入）”；
- 在
dragenter和dragover中调用e.preventDefault()，同时设置e.dataTransfer.dropEffect = 'copy'（不是'none'，否则视觉反馈消失） - 在
drop事件中立即e.preventDefault()，防止浏览器尝试解析并插入文件内容 - 若编辑器使用 ProseMirror 或 Slate，确保自定义
handleDrop插件返回false，避免被框架内部拦截处理 - 拖拽期间临时移除
contenteditable="true"（设为false），drop后再恢复，可彻底杜绝意外插入
dragover → 阻止默认 → 显示高亮 → drop 时提取 files 或降级处理 items → 上传 → 清理状态。但每个环节都卡在细节上，比如 Safari 的 items 为空、contenteditable 的隐式粘贴、移动端根本没 DataTransfer.files……这些不是边缘情况，而是必现问题。 
