ThinkPHP上传安全需四层防护：服务器禁PHP执行、白名单+MIME+重命名校验、路径与URL分离、临时文件及时清理。
ThinkPHP 上传目录为什么不能直接禁用 PHP 执行
因为很多老项目会把 public/uploads 这类目录放在 Web 根目录下，而 Apache/Nginx 默认允许该目录下所有 .php 文件被解析执行。一旦攻击者绕过上传校验（比如用 .php.jpg 双后缀、空字节截断、Content-Type 伪造），上传成功后就能直接访问执行——这是后门最常见路径。
所以单纯靠“禁止上传 PHP 文件”不牢靠，必须配合服务器层限制执行权限：
- Apache：在上传目录的
.htaccess中写php_flag engine off或RemoveHandler .php - Nginx：在对应
location块中加deny all;或明确禁止.php解析，例如：location ~ ^/uploads/.*\.php$ { return 403; } - Linux 权限层面：确保上传目录对 Web 进程是
755，且不属www-data（或nginx）用户，避免写入可执行脚本
ThinkPHP 自带上传类的后缀白名单怎么设才有效
很多人只改了 exts 参数，但没意识到 ThinkPHP 的 FileValidate 默认只校验扩展名，不解析文件头或 MIME 类型——攻击者改个后缀就能绕过。
正确做法是组合验证 + 强制重命名：
立即学习“PHP免费学习笔记（深入）”；
- 必须显式设置
exts，例如：['jpg', 'jpeg', 'png', 'gif']，不要留空或写['*'] - 开启
type验证（检查 MIME）：'mimes' => ['image/jpeg', 'image/png', 'image/gif'] - 强制关闭自动识别后缀：
'auto_rename' => true，并配合'sub_dir' => false控制子目录逻辑 - 关键一步：上传后立即用
exif_imagetype()或finfo_file()再校验真实类型（尤其对图片类业务）
为什么上传后的文件路径和 URL 要分离处理
ThinkPHP 默认返回的 $file->getSaveName() 是相对路径，如果直接拼进 HTML 输出或日志，可能触发路径遍历（如上传 ../../etc/passwd）；更危险的是，有些开发者会把保存路径直接 echo 出来供前端下载，结果暴露了真实物理路径。
安全做法是切断“存储路径”和“可访问 URL”的映射关系：
- 上传时统一存到非 Web 目录（如
runtime/upload/），再通过控制器代理下载，避免直接暴露路径 - 若必须放
public下，URL 必须走路由控制，例如用/api/download?id=xxx，而不是/uploads/2024/xx.php - 所有返回给前端的文件名，必须经过
basename()和正则过滤（只留字母、数字、下划线、点）
上传临时文件未清理导致的隐藏风险
ThinkPHP 在上传失败或中断时，tmp_name 对应的临时文件可能残留，尤其在并发高、磁盘满、异常退出场景下。这些文件虽无扩展名，但内容可能是恶意代码，一旦被猜中路径或配合其他漏洞（如 LFI），就能被包含执行。
必须主动管理临时生命周期：
- 上传完成后立刻调用
$file->move()，不要长期依赖$_FILES['x']['tmp_name'] - 在
catch或finally中手动unlink($_FILES['x']['tmp_name']) - 定期用脚本清理
/tmp或runtime/temp下超过 1 小时的临时文件（ThinkPHP 本身不自动清理）
真正麻烦的不是配置多难，而是上传流程里有太多“默认不报错但实际失效”的环节——比如 mimes 校验在某些 PHP 版本下静默跳过，或者 Nginx 的 location 规则被更高优先级的 ~ \.php$ 覆盖。上线前一定得用真实畸形文件测一遍完整链路。
