draggable 属性与拖拽上传无关，因其仅控制网页内元素拖动；拖拽上传依赖 dragover/drop 事件及 preventDefault()，而非 draggable 或已废弃的 dropzone 属性。
draggable 是 HTML 元素的全局布尔属性，但它和“拖拽上传”没有直接关系；真正的拖拽上传不依赖它，也不需要设置 draggable="true" —— 用户拖的是操作系统里的文件，不是网页上的 DOM 元素。
为什么给上传区域加 draggable="true" 是错的
这个属性只影响“网页内元素能否被用户拖动”，比如拖动卡片排序。而文件上传场景中，拖拽源是桌面文件系统，浏览器自动将其作为 DataTransfer 对象传入页面，与页面上任何元素是否可拖无关。强行加 draggable="true" 不但无用，还可能干扰事件冒泡（尤其当容器里有子元素时），甚至触发多余的 dragstart 事件，导致视觉反馈错乱或 drop 被拦截。
- 拖拽上传的目标区域（如
<div id="upload-area">）只需监听dragover和drop - 不要在该容器或其子元素上设
draggable属性 - 若用了第三方 UI 组件（如 Element Plus 的
<el-upload>），确认它没内部误设draggable—— 有些旧版组件会默认开启，需 CSS 强制覆盖：div[draggable] { draggable: false !important; }
dropzone 不是标准属性，现代浏览器已弃用
dropzone 属性曾出现在早期草案中，值为 copy/move/link，但从未成为正式标准，且 Chrome 从 100+、Firefox 从 90+ 版本起已完全忽略它。现在所有主流浏览器（Chrome、Firefox、Edge、Safari 16.4+）都只认 JS 事件逻辑：只要 dragover 中调用了 preventDefault()，该元素就是有效 drop target。
- 写
dropzone="copy"不会报错，但也不会起作用 - 不要把它当作兼容性兜底手段——它在 Electron 或旧版 WebView 中也可能失效
- 真正可靠的“兜底”是确保容器有明确宽高、非
display: none、且父级没设pointer-events: none或overflow: hidden（后者会截断拖拽阴影）
跨域上传的关键不在 drag/drop，而在 fetch 或 XMLHttpRequest 配置
拖拽本身不涉及跨域限制；限制来自后续的文件上传请求。浏览器对 fetch 或 XMLHttpRequest 发起的跨域请求执行 CORS 检查，与拖拽过程无关。
立即学习“前端免费学习笔记（深入）”；
- 后端必须返回正确的 CORS 头，例如：
Access-Control-Allow-Origin: https://your-frontend.com，且不能为*（如果前端带 credentials） - 前端上传时若需携带 cookie 或认证头，必须显式设置：
credentials: 'include'（fetch）或withCredentials = true（XMLHttpRequest） - 不要试图在
drop事件里改dataTransfer去“绕过跨域”——dataTransfer.files是只读的，也无法注入 Origin 或 Referer - 常见错误：上传失败报
net::ERR_FAILED或控制台显示 CORS 错误，却去调试 dragover 逻辑——问题一定出在 fetch 请求配置或后端响应头
真正容易被忽略的是：拖拽区域的事件监听必须绑定在“能接收鼠标事件”的真实 DOM 上，而不是靠 CSS 定位悬空的伪元素；另外，移动端不支持原生拖拽，这个方案只适用于桌面环境，别指望它在 iOS Safari 里工作。
