HTML 中 files[0].type 不可靠，因其仅基于文件扩展名猜测 MIME 类型；必须通过 FileReader 读取文件头（magic bytes）前端预筛，并由服务端二次校验原始内容。
一个常见的误解是，HTML 本身就能搞定文件类型检测。实际上，input[type="file"] 提供的 files[0].type 属性，不过是浏览器根据文件扩展名“猜”出来的 MIME 类型。这东西，本质上不可信，也绝不能替代基于文件真实内容的检测。
为什么不能只用 files[0].type
这个字段的来源很简单：浏览器读取文件后缀（比如 .jpg），然后去查一张内置的映射表。它压根不会去读文件头。这意味着，用户只要改个后缀名，就能轻松绕过。比如，把 shell.php 改成 shell.jpg，files[0].type 就会变成 image/jpeg，可文件里装的却是 PHP 代码。如果服务端只校验这个字段，那无异于为上传漏洞敞开了大门。
- 无论是 Chrome、Safari 还是 Firefox，它们都不会解析文件内容，
.type纯粹是一个基于客户端的推测值。 - 当文件没有后缀、后缀为空，或者使用了双后缀（如
photo.jpg.php）时，这个字段常常会返回空字符串或者text/plain。 - 更麻烦的是，不同操作系统下的行为还不一致。比如，Windows 系统可能会把一个 CSV 文件报告为
application/vnd.ms-excel，而 Mac 系统则可能报text/csv或text/plain。
前端用 FileReader.readAsArrayBuffer() 读 magic bytes
那么，前端有没有可靠的办法呢？答案是肯定的。在不发送请求的前提下，唯一可靠的方式就是直接读取文件开头的几个字节，也就是所谓的“magic number”（文件头签名），并与已知的签名进行比对。
- 通常，读取前 12 个字节就足够了：JPEG（以
0xFF 0xD8开头）、PNG（0x89 0x50 0x4E 0x47）、GIF（0x47 0x49 0x46）、WebP（以“RIFF...WEBP”开头）等常见格式都能判断出来。 - 这里有个关键点：必须使用
readAsArrayBuffer()方法，而不能用readAsText()，因为后者会触发编码转换，破坏原始的二进制数据。 - 为了性能考虑，可以用
file.slice(0, 12)只截取文件头部，这样既能避免大文件阻塞主线程，也能减少内存占用。
function detectMimeType(file) {
return new Promise(resolve => {
const reader = new FileReader();
reader.onload = () => {
const buf = new Uint8Array(reader.result);
if (buf[0] === 0xff && buf[1] === 0xd8) resolve('image/jpeg');
else if (buf[0] === 0x89 && buf[1] === 0x50 && buf[2] === 0x4e && buf[3] === 0x47) resolve('image/png');
else if (buf[0] === 0x47 && buf[1] === 0x49 && buf[2] === 0x46) resolve('image/gif');
else if (buf[0] === 0x52 && buf[1] === 0x49 && buf[2] === 0x46 && buf[3] === 0x46 &&
buf[8] === 0x57 && buf[9] === 0x45 && buf[10] === 0x42 && buf[11] === 0x50) resolve('image/webp');
else resolve('application/octet-stream');
};
reader.readAsArrayBuffer(file.slice(0, 12));
});
}
服务端必须做二次校验，且优先依赖内容探测
前端预筛固然重要，但服务端的二次校验才是最终防线，而且必须优先依赖对文件内容的探测。不同技术栈都有成熟的方案：Node.js 可以用 file-type 库，PHP 用 finfo_file() 函数，Python 则可以结合 mimetypes.guess_type() 和 python-magic 库。核心原则是：必须传入原始的文件内容（或临时文件路径）进行分析，绝不能只看 $_FILES['f']['type'] 或者文件后缀。
立即学习“前端免费学习笔记（深入）”；
- 其实，Linux/macOS 系统下的
file -i命令，底层原理和前端检测一模一样，都是通过读取/usr/share/misc/magic这类文件来匹配 magic bytes。 - 需要警惕的是，PHP 中的
$_FILES['f']['type']完全来自 HTTP 请求头里的Content-Type，这个值可以被 Burp Suite 等工具轻易篡改。 - 所以，即使前端已经做了 magic bytes 校验，服务端也必须重新做一遍。因为文件可能在传输过程中损坏，或者前端的检测逻辑被绕过。
accept 属性只是 UI 提示，不是安全机制
最后，必须澄清一个误区： 里的 accept 属性，仅仅是一个用户体验优化项。它只影响文件选择器弹窗里默认显示哪些类型的文件，而不会限制用户的实际选择（用户依然可以点击“所有文件”来强行选择任何类型）。它既不会阻止用户选择一个 .exe 文件，也不会改变 files[0].type 的值。
- 不同浏览器的行为也有差异：Chrome 在 macOS 上对
accept=".pdf"可能会过滤掉非 PDF 文件图标，但在 Windows 下基本无效。 - 移动端的 Safari 浏览器甚至会忽略大部分
accept值，仅支持image/*、video/*、audio/*这类通配符。 - 结论很明确：永远不要把
accept属性当作任何形式的校验依据。它的作用仅限于改善用户体验，降低用户误操作的概率。
总而言之，一套真正可靠的文件类型检测方案，永远需要两层防护：前端进行快速预筛（基于 magic bytes），服务端进行权威判定（基于内容探测）。任何只依赖单侧、仅看后缀名或 HTTP 头的方案，在生产环境中都等同于门户大开，毫无防御可言。
