必须用 finfo_file() 读文件头判断真实 MIME，$_FILES'file' 和扩展名都不可信——前者由浏览器生成可伪造，后者可通过 evil.PHP.jpg 等方式绕过；真正类型需通过文件魔数识别，finfo_file() 配合 FILEINFO_MIME_TYPE 才可靠。
必须用 finfo_file() 读文件头判断真实 MIME，$_FILES['file']['type'] 和扩展名都不可信——前者是浏览器传的，后者能随便改。
为什么不能信 $_FILES['file']['type']
这个值由浏览器生成，改个 Content-Type 请求头就能伪造。比如把 shell.php 改成 shell.jpg 并手动设 Content-Type: image/jpeg，后端就收不到任何警告。
-
$_FILES['file']['type']是客户端可控字段，连基本校验都不算 - 哪怕配合
pathinfo($_FILES['file']['name'], PATHINFO_EXTENSION)提取扩展名，也挡不住evil.PHP.jpg或shell.php%00.jpg这类绕过 - 真正类型得看文件开头那几个字节（魔数），只有
finfo_file()能稳定读出来
finfo_file() 怎么用才不白配
不是调一下函数就行，漏掉关键参数或环境检查，结果可能还是错的。
- 先确认 PHP 启用了
fileinfo扩展：php -m | grep fileinfo，没输出就得重编译或开配置 - 创建资源时必须用
FILEINFO_MIME_TYPE：finfo_open(FILEINFO_MIME_TYPE)，否则返回带charset的完整字符串，比如image/jpeg; charset=binary，直接比对会失败 - 传参必须是
$_FILES['file']['tmp_name']，不是原始文件名；且要先用is_uploaded_file()确认它真是上传来的，防路径穿越 - 返回值是纯 MIME 字符串，如
image/png，白名单得写成['image/jpeg', 'image/png', 'application/pdf']，别用strpos()模糊匹配
只验 MIME 还不够，必须加扩展名映射
MIME 只说明内容格式，不保证扩展名安全。比如 image/svg+xml 是合法图片 MIME，但 SVG 文件里能嵌 JS，直接放 Web 目录就有 XSS 风险。
立即学习“PHP免费学习笔记（深入）”；
- 建一个严格映射表：
['image/jpeg' => 'jpg', 'image/png' => 'png', 'application/pdf' => 'pdf'] - 用
pathinfo($_FILES['file']['name'], PATHINFO_EXTENSION)提取扩展名，再strtolower()统一小写 - 比对时必须是「MIME 存在于映射键中」且「提取的扩展名等于对应值」，二者缺一不可
- 注意：有些 MIME 类型有多个常见扩展（如
image/jpeg对应jpg和jpeg），白名单里两个都得列
move_uploaded_file() 前必须卡死三道关
前面所有检查都是为这一步服务。漏掉任意一环，恶意文件就落地了。
- 第一关：
finfo_file()返回的 MIME 在白名单内 - 第二关：提取的扩展名和 MIME 映射完全一致
- 第三关：
$_FILES['file']['size']≤ 自定义上限（比如 5MB），且$_FILES['file']['error'] === UPLOAD_ERR_OK - 目标路径必须是绝对路径，目录存在、PHP 进程有写权限，且**绝不能放在 Web 可访问路径下**（如
public/或htdocs/） - 文件名必须重命名，用
uniqid() . '.' . $allowedExt这类方式，避免覆盖或解析漏洞
最容易被忽略的是：finfo_file() 必须在 move_uploaded_file() 之前调用，且临时文件路径必须可读。有些框架或中间件会自动清理 tmp_name，一旦延迟验证，finfo_file() 就读不到内容，返回 false，反而导致逻辑跳过校验。
