dataTransfer.files是唯一可靠入口，必须从中获取FileList并遍历File对象；File.type可能为空，需结合文件名后缀fallback判断，不可信且无法替代服务端校验。
拖拽文件时 dataTransfer.files 是唯一可靠入口
浏览器不提供独立的“文件类型探测 API”，所有类型信息都必须从 File 对象上读取。拖拽事件的 drop 或 dragend 阶段，只能通过 event.dataTransfer.files 拿到 FileList，再遍历每个 File 实例。
注意：event.dataTransfer.types 在拖拽文件时通常只返回 Files 字符串，不是 MIME 类型，不能用于判断图片还是 PDF。
-
File.type是最直接的字段，但可能为空（尤其 Windows 上拖拽本地文件时） - 必须配合
File.name后缀做 fallback 判断，不能只信type - 不要尝试用
event.dataTransfer.getData('text/plain')或类似方式读取类型——对文件无效
File.type 为空时怎么补救
很多场景下 File.type 是空字符串，比如用户从资源管理器拖入一个 report.pdf，file.type 可能为 ''。这时得靠文件名后缀映射 MIME 类型。
简单可靠的 fallback 方式是提取 File.name 的扩展名，查表转换：
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
function getMimeType(file) {
if (file.type) return file.type;
const ext = file.name.split('.').pop().toLowerCase();
const mimeMap = {
'jpg': 'image/jpeg',
'jpeg': 'image/jpeg',
'png': 'image/png',
'gif': 'image/gif',
'pdf': 'application/pdf',
'txt': 'text/plain'
};
return mimeMap[ext] || 'application/octet-stream';
}
- 仅靠后缀无法 100% 准确（如伪造后缀的文件），但对前端校验、图标展示、上传前提示已足够
- 不要用正则或
lastIndexOf('.')提取后缀——文件名可能含多个点（archive.tar.gz） - 如果需强校验类型，必须服务端读取文件头（magic bytes），前端无法替代
为什么 File.type 有时不准或为空
这个行为由操作系统和浏览器共同决定：File.type 来源于系统提供的文件元数据，而非文件内容本身。
- macOS 拖拽通常能给出较准的
type（基于 UTI） - Windows 资源管理器拖拽时，多数情况
type为空，因为 Explorer 不主动提供 MIME 类型 - Chrome 和 Edge 行为基本一致；Firefox 对某些本地文件会尝试 sniff，但也不稳定
- 即使
type非空，也可能被用户修改过注册表或文件关联，不可信
需要更准的类型检测？别在前端硬刚
真要区分 image/webp 和 image/jpeg，或者识别无后缀的二进制文件，前端没标准 API 可用。可行路径只有两个：
- 用
FileReader读取前几百字节，手动比对 magic bytes（复杂且有性能开销） - 把文件 Blob 传给后端，用
file命令或库（如 Python 的python-magic）识别，再回传结果
绝大多数业务场景中，“后缀 fallback + File.type 优先” 已覆盖 95% 用例。过度追求前端精准识别，容易掉进兼容性和维护成本的坑里。
