PHP 7.4 中仅用 in_array() 校验后缀名无法防御恶意文件上传，必须结合 pathinfo() 提取扩展名、strtolower() 统一大小写、非空检查、finfo_file() 验证真实 MIME 类型、严格路径隔离及 upload error 检查，缺一不可。
PHP 7.4 中仅靠 in_array() 判断后缀名白名单，**根本拦不住恶意文件**。它只是第一道门缝，不补上 finfo_file() 和路径隔离，攻击者分分钟把 shell.jpg.php 或空字节截断的 webshell.php%00.jpg 落地到你的服务器上。
为什么 pathinfo() + in_array() 必须配合 strtolower() 和非空检查
浏览器传来的 $_FILES['file']['name'] 是完全可控的：可能带路径（../../etc/passwd）、大小写混用（Shell.PHP）、多个点（readme.jpg.php），甚至无扩展名（exploit. 或纯 .）。
-
pathinfo($name, PATHINFO_EXTENSION)是唯一可靠提取方式，substr(strrchr($name, '.'), 1)会漏掉abc.这类边界情况 - 必须
strtolower($ext)后再比对，否则.JPG、.Pdf直接被拒 - 要显式检查
!empty($ext)，空字符串意味着用户上传了无扩展名或仅含点的文件，应直接拒绝 - 白名单数组必须硬编码，如
$allowed_exts = ['jpg', 'jpeg', 'png', 'pdf'];，避免从配置文件或数据库动态读取引入不可信字符
finfo_file() 是绕过扩展名校验的唯一解药
攻击者改 POST 的 name 字段为 backdoor.php，但服务端收到的仍是临时文件 /tmp/phpabc123 —— 它的真实内容可能是 JPEG 图片，也可能是 PHP 木马。$_FILES['file']['type'] 和后缀都可伪造，只有二进制头（魔数）骗不了人。
- 必须在
move_uploaded_file()之前调用finfo_file()，否则恶意内容已写入磁盘 - 启用
FILEINFO_MIME_TYPE模式，返回类似image/png或application/pdf的标准 MIME 字符串 - 白名单映射需严格：比如允许
pdf扩展名，就只接受application/pdf，拒绝application/x-php即使它伪装成 PDF - PHP 7.4 默认启用
fileinfo扩展，但上线前仍需确认extension=fileinfo.so在php.ini中未被注释
move_uploaded_file() 前必须检查的三个硬性条件
跳过任意一项，后续所有校验都失去意义——因为文件可能根本没上传成功，或压根不是合法上传产生的临时文件。
立即学习“PHP免费学习笔记（深入）”；
-
$_FILES['file']['error'] === UPLOAD_ERR_OK（即0），否则是上传失败（超限、无文件、临时目录不可写等），不能继续处理 -
is_uploaded_file($_FILES['file']['tmp_name'])必须返回true，防止攻击者用file_get_contents('/etc/passwd')伪造临时路径 -
move_uploaded_file()的目标路径必须用basename()清洗原始文件名，并生成服务端唯一名称（如uniqid() . '_' . $safe_ext），禁止拼接用户输入的完整name - 目标目录绝不能在 Web 根目录下；若必须访问，Nginx 需配
location ~ \.php$ { deny all; }，Apache 需禁用AllowOverride All或移除ExecCGI
真正卡住上传风险的，从来不是“能不能识别 .php”，而是“有没有让真实内容和扩展名强制一致”+“落地路径是否彻底与执行环境隔离”。in_array() 只负责守门，finfo_file() 负责验货，move_uploaded_file() 配合权限控制才负责锁仓——少一环，整套防护就形同虚设。
