在使用ThinkPHP进行文件上传时，ext扩展名验证通常是开发者首先接触的关键环节。但你真的了解它的实际工作原理吗？它仅比对文件名后缀，而不读取文件内容，甚至对空格和大小写都极其敏感。更为重要的是——它是TP文件上传验证五层防线中不可忽视的第一道关卡，一旦配置遗漏，整个validate验证链将直接失效。
为什么必须强调“要验证扩展名”？原因很简单：仅依赖扩展名当然不安全，但它却是整个校验链条中的首道屏障——如果不设置白名单，连最基本的过滤都不存在，后续的所有验证都将形同虚设。
ext规则仅校验文件名后缀，不读取文件实际内容
ThinkPHP中的 validate(['ext' => ['jpg', 'png']]) 这行代码，实际上是从 $_FILES['file']['name'] 中提取最后一个点号之后的部分（例如将 shell.php.jpg 提取为 jpg），然后与白名单中的值逐个比对。它既不会打开文件读取字节，也不会使用 finfo_open() 来探测真实文件类型。
- 攻击者只需将
webshell.php重命名为avatar.jpg，就能轻松绕过此层验证 - 若规则写成
'JPG'或'.jpg'都会失败——必须使用全小写、不带点、逗号分隔的格式：'jpg,png,gif' - 空格同样会导致问题：
report .pdf的扩展名会被识别为' pdf'（前面带空格），验证直接报错
不配置ext就等于未启动validate()验证链
ThinkPHP 6+ 默认不会自动触发任何上传验证。如果你只配置了 size 或 type，却遗漏了 ext，整个 validate() 调用可能无声跳过——尤其是方法使用错误时：validate() 是模型方法，对文件对象无效；必须使用 rule() 或 validateRule() 绑定到 thinkFile 实例。
- 如果表单缺少
enctype="multipart/form-data"，request()->file()会返回 null，后续所有验证均不执行 - 未配置
ext规则，即使写了type，TP 也可能因逻辑短路而不进入 MIME 校验分支 ext是唯一能够快速拦截明显非法后缀（如.exe、.php）的低成本手段，这笔成本不应节省
ext和type必须分别配置，不可混用
ThinkPHP 对 ext 和 type 的处理是互斥的：如果规则中同时包含 ext 和 type，框架会优先执行 ext 路径，直接忽略 type——这并非 bug，而是设计如此。
- 若要使用真实 MIME 校验，则需删除
ext，仅保留type，并配合'mime' => false关闭对客户端$_FILES['file']['type']的信任 - 更稳妥的做法是两套规则都配置，但分两次调用：先用
$file->validate(['ext' => [...]])通过第一关，再手动使用finfo_file()进行第二关 - 注意：
jpeg和jpg在 TP 中被视为不同的扩展名，白名单中最好都包含
回到最初的疑问：真正危险的并非“为什么必须验证扩展名”，而是误以为验证了扩展名就万事大吉。它只是门禁卡，而非安检仪。后续的四层防线——真实 MIME 校验、文件重命名、非 Web 目录存储、服务器禁用执行权限——缺一不可。而 ext 规则，是唯一一个只需配置即可立即生效的屏障。
