应在dragenter阶段用e.dataTransfer.items检查item.kind==='file'及item.type，匹配白名单MIME类型并即时反馈；drop时再校验文件名扩展名、大小及完整性，前后端协同防伪防越界。
拖拽时怎么提前识别非允许文件类型
不能等用户松手（drop）才校验——那时已错过交互时机，且 Safari 拖入文件夹会返回一个 68 字节的伪 File，files.length > 0 为真但后续上传必失败。真正靠谱的方式是在 dragenter 阶段用 e.dataTransfer.items 检查 MIME 类型。
-
e.dataTransfer.items在dragenter和dragover中都可用，且不依赖文件实际加载，能立刻拿到item.type - 只检查
item.kind === 'file'再比对item.type，避免把拖进来的网页链接、纯文本误判为文件 - 别写
if (e.dataTransfer.files.length)——它在dragenter里不可靠，Safari 下可能为空或滞后 - 示例判断逻辑：
if (item.type && !['image/jpeg', 'image/png'].includes(item.type))，匹配失败就加invalid类并显示提示
drop 事件里怎么安全地二次校验并报错
drop 是最终确认环节，必须做兜底检查：此时 e.dataTransfer.files 才是完整、可读的 FileList，但得防空、防伪、防越界。
- 先判空：
if (!e.dataTransfer.files.length) return，防止跨窗口拖拽或浏览器兼容问题导致空列表 - 逐个取
file后，用file.name.split('.').pop().toLowerCase()提取扩展名，比file.type更稳定（后者在拖拽时经常为空或被伪造） - 大小校验别漏：
if (file.size > 20 * 1024 * 1024)，超限直接alert或 UI 提示，并清空状态 - 报错后别留“残影”：调用
URL.revokeObjectURL(previewUrl)（如果之前生成过预览），避免内存泄漏
为什么只靠 accept 属性无法拦截错误格式
accept 只影响原生 <input type="file"> 的文件选择器弹窗，对拖拽上传完全无效——拖拽绕过了这个限制，浏览器不会主动过滤或提示。
-
accept=".jpg,.png"对拖拽无约束力，用户照样能拖 .exe、.zip 进来 - 移动端尤其明显：iOS Safari 基本忽略
accept，连选择器里的过滤都不保证 - 后端仍需用魔数（magic bytes）校验真实类型，前端校验纯属体验层，不能替代服务端检查
- 常见错误是把
accept="image/*"当成万能开关，结果上传接口收到一堆text/plain或空type的文件
报错后 UI 状态怎么不卡死
上传失败 ≠ 界面失联。最常被忽略的是：用户拖进去了、你报错了、但“上传中” loading 状态没关，按钮也没恢复，整个区域变灰失效。
立即学习“前端免费学习笔记（深入）”；
- 每个文件建议独立跟踪状态，比如用
Map存file.uid → { status: 'error', message: '不支持的文件类型' } - 报错后必须显式重置 UI：移除
hover类、隐藏预览图、恢复按钮可点击态、清空临时FormData - 别用全局布尔值控制 loading，否则一个文件失败，其他排队文件也动不了
- 网络中断时
fetch不进catch，得靠!response.ok || response.status >= 400判断是否真失败
拖拽上传的报错逻辑不是“弹个 alert 就完事”，而是要在 dragenter 阻断、drop 核验、UI 同步三处全部对齐；任何一层脱节，用户都会觉得“我明明拖进去了，怎么没反应”。
