file.type不可靠，须结合name后缀、type及二进制签名多层校验；因系统不提供MIME时该字段为空，Windows/macOS/Safari均存在此问题，实操应优先用后缀映射，关键场景读magic number，并校验file.size>0防伪文件。
拖拽进来的文件类型不能靠 e.dataTransfer.files[0].type 盲信，尤其在 Safari 和 Chrome 中，这个字段经常为空或不可靠；真正可用的判断方式是结合 file.name 后缀、file.type、甚至二进制签名（magic number）做多层校验。
为什么 file.type 经常是空字符串？
浏览器只在操作系统能明确提供 MIME 类型时才填充该字段。Windows 资源管理器不传 MIME，macOS 对某些自定义扩展名也不识别，Safari 更是默认清空 type（哪怕文件是 .png）。你看到 file.type === "" 不是 bug，是常态。
实操建议：
- 永远把
file.type当作可选提示，而非判断依据 - 优先用
file.name.split('.').pop().toLowerCase()提取后缀，再映射到常见类型（如"jpg"→"image/jpeg"） - 对关键业务（如上传头像、解析 CSV），必须读取文件前 4–8 字节做 magic number 检查（例如 PNG 开头是
89 50 4E 47）
dataTransfer.items 与 dataTransfer.files 的类型差异
dataTransfer.items 是 DataTransferItem 列表，每个 item 有 kind（"file" 或 "string"）和 type（如 "text/plain"）；而 dataTransfer.files 是 FileList，只含 File 对象，type 来自系统且不稳定。
所以：如果你需要在 dragenter 或 dragover 阶段就反馈“只接受图片”，就得遍历 items：
.exe
- 用正则提取最后一个点后的部分：
file.name.match(/\.([^.]+)$/)?.[1] || ''，避免foo.bar.txt错判为txt - 统一转小写比较，防止
.JPG被忽略 - 对图片/文档类文件，加一层
file.size 限制，过滤掉明显异常的大文件（比如 200MB 的 “.jpg”） - 不要用
file.type.startsWith('image/')做唯一判断——Safari 拖进来 jpg，file.type可能是""，但file.name是"a.jpg"
移动端根本没 dataTransfer.files，别白费劲
iOS 和 Android 浏览器（包括 Chrome for Android）不支持 dragover/drop 事件读取本地文件。你写的整套拖拽逻辑，在手机上点击都不会触发——这不是兼容性问题，是 API 根本未实现。
应对方式只有一条：
- 用
作为降级入口，并隐藏它，用按钮样式包裹 - 检测
'ontouchstart' in window或navigator.maxTouchPoints > 0，直接禁用拖拽区域，显示“请点此选择文件”提示 - 别试图 polyfill 拖放——没有底层支持，JS 层怎么绕都是徒劳
最常被忽略的一点：即使你拿到了 file 对象，也得立刻检查 file.size > 0。Safari 拖文件夹进来会产生 size=68 字节的伪文件，file.type 和 file.name 都看起来正常，但后续 FileReader 读取会失败或返回乱码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
