dragenter阶段无法可靠获取扩展名，只能用dataTransfer.items.kind==='file'和type粗筛；扩展名校验必须在drop事件中通过Array.from(files)提取name并split('.').pop()安全获取，再比对白名单。
dragenter 里怎么提前判断扩展名是否合法
不能等 drop 才校验——那时用户已经松手，体验断层。真正该做的是在 dragenter 阶段就拿到文件名、提取扩展名、比对白名单，并立刻给视觉反馈（比如高亮变红或显示提示）。但注意：e.dataTransfer.files 在 dragenter 里不可靠（Safari 可能为空，Android WebView 兼容差），得用 e.dataTransfer.items。
关键点是：items 的每个 DataTransferItem 对象有 kind === 'file' 和 type 属性，但 type 是 MIME，不是扩展名；而扩展名只能从 getAsFile() 后的 name 字段取——但这个操作会触发异步读取，在 dragenter 这种高频事件里不能直接 await。
所以实际可行的折中方案是：仅用 type 做粗筛（如 image/jpeg → 接受，text/plain → 拒绝），再配合后续 drop 时的扩展名精筛。若业务强依赖扩展名（比如只允许 .xlsx 不接受 .xls），那 dragenter 阶段就只能显示“可能不支持”，真正拦截必须放在 drop 之后。
drop 事件里如何安全提取并校验扩展名
drop 事件才是稳定获取 File 对象的时机。此时 e.dataTransfer.files 是可靠来源，但仍有几个坑要绕开：
- 必须先调用
e.preventDefault()，否则浏览器会默认打开/下载文件 -
e.dataTransfer.files是只读FileList，不能直接用filter或map，得先转成数组：Array.from(e.dataTransfer.files) - 某些 Safari 版本拖入文件夹时，
files[0].size === 68且name无扩展名，需显式过滤：file.size > 0 && file.name.includes('.') - 提取扩展名别用
file.name.split('.')[1]—— 文件名带多个点（如archive.tar.gz）会出错；改用：file.name.split('.').pop().toLowerCase() - 白名单比对建议用
includes而非正则，更直观不易错：['.jpg', '.jpeg', '.png'].includes(ext)
为什么不能只信 file.type，还得看扩展名
file.type 是浏览器根据文件头或扩展名推测的 MIME，极不可靠：
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 拖拽上传时，
file.type经常为空字符串或"" - 用户把
evil.exe改名为safe.jpg，file.type就会变成image/jpeg，但真实内容是可执行文件 - 某些 Android WebView 下，
file.type固定返回application/octet-stream，完全失效
所以扩展名是前端唯一能低成本、高一致性拿到的线索。它虽可伪造，但和 file.type 一起用，能覆盖 95% 的误操作场景——比如用户真想传个 .pdf 却手滑选了 .exe，扩展名一查就露馅。
后端为什么必须重验扩展名和文件头
前端校验只是防手误，不是防攻击。所有上传请求到达后端时，必须做两件事：
- 忽略 HTTP 请求头里的
Content-Type，用库（如 Node.js 的file-type、Python 的python-magic）读取文件前几百字节，识别 magic number，得到真实 MIME - 检查客户端传来的原始文件名扩展名是否在白名单内，且与真实 MIME 类型逻辑自洽（例如
.jpg应对应image/jpeg，而非application/x-executable） - 对
.html、.js、.zip等高风险类型，即使扩展名合法，也要额外加沙箱处理或拒绝存储
最易被忽略的一点：前端传上来的 file.name 是用户可控字段，后端保存时必须重命名（如 UUID + 白名单扩展名），绝不能直接用原名落盘。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
