PHP finfo_file 判断上传类型时为什么不能只看扩展名

上传接口里最容易留下的误区，是看到文件名以 .jpg 结尾，就把它当成图片。这个判断只看到了文件名，不知道文件内容；而 $_FILES['type'] 又是浏览器提交的 MIME 声明，同样不能当作服务端证据。更稳妥的做法是：先检查上传状态和临时文件，再用 finfo_file() 读取内容类型，最后把识别结果交给业务白名单和后续图片处理。

扩展名、浏览器声明和文件内容不是同一层信息

一次上传实际上带来三类信号：$_FILES['name'] 是用户提交的原始文件名，扩展名可以随意改；$_FILES['type'] 是浏览器提供的 MIME 值，PHP 手册明确提醒它没有在 PHP 侧完成可靠验证；临时文件本身才是服务端可以读取的对象。三者相同，只能说明输入看起来一致，不能说明它一定是安全图片。

因此，下面这类判断只能筛选名称，不能完成类型鉴别：

用 finfo_file 读取临时文件的 MIME 类型

Fileinfo 扩展会根据文件中的特征字节和其他启发式信息推断类型。使用 FILEINFO_MIME_TYPE 时，结果通常是 image/jpeg、image/png 或 application/octet-stream 这样的 MIME 字符串；失败时返回 false。它解决的是“内容更像什么”，不是“业务一定允许什么”。

这里的关键不是把 finfo_file() 写出来，而是把它的输入固定为服务端临时文件。若拿原始文件名、表单 MIME 或用户可控路径去判断，识别链条仍然没有闭合。

把类型识别接到上传白名单，而不是直接信任结果

识别得到 MIME 后，还要由业务决定是否允许。比如头像只允许 JPEG、PNG 和 WebP，可以用明确映射同时约束 MIME 与最终扩展名；不要把用户原名拼接到上传目录，也不要因为 MIME 识别成功就直接认为文件可公开访问。

 'jpg',
    'image/png'  => 'png',
    'image/webp' => 'webp',
];

if (!isset($allowed[$mime])) {
    throw new RuntimeException('不接受该文件类型');
}

// 服务端重新生成名称，避免使用原始文件名和路径片段。
$storedName = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
$destination = __DIR__ . '/uploads/' . $storedName;
if (!move_uploaded_file($tmpName, $destination)) {
    throw new RuntimeException('上传文件保存失败');
}

对图片业务，白名单仍只是第一道门。需要缩略图、头像或公开展示时，再按风险补充尺寸限制、解码检查、重新编码、存储目录不可执行和访问权限控制。Fileinfo 的启发式判断很有用，但手册也没有把它描述成“绝对可靠的安全证明”。

常见误判与上线前检查清单

上线前可以按这条顺序复查：是否先处理 UPLOAD_ERR_OK；是否只对临时文件调用 finfo_file()；是否拒绝 false 和不在白名单中的 MIME；是否重新生成存储名；图片是否还有尺寸、解码和重新编码要求。若业务只需要保存任意附件，还要把允许类型、大小、下载响应头和隔离存储一起定义，不能只改一个扩展名判断。

常见问题

finfo_file() 和 pathinfo() 是不是二选一？

不是。pathinfo() 可以提取展示或存储策略所需的扩展名，finfo_file() 负责从内容角度提供类型线索；两者解决的问题不同。

为什么 finfo_file() 返回 application/octet-stream？

这表示当前内容没有被可靠识别为更具体的类型，或文件特征不符合常见规则。业务通常应把它当作需要拒绝或人工处理的结果，而不是强行改成 jpg。

识别出 image/jpeg 后就可以直接公开文件吗？

不能。还要按场景检查大小、尺寸、解码与重新编码策略，并确保上传目录和下载响应不会把文件当成可执行脚本处理。