PHP 文件上传怎么做才安全：从 $_FILES 校验到落盘和清理

PHP 文件上传最容易出问题的地方，不是 move_uploaded_file() 这一行，而是保存之前的校验做得太敷衍：只检查扩展名、完全信任浏览器传来的文件名、把文件直接丢进全站可访问的路径，这些操作都会给后续的安全排查埋坑。更稳妥的实现思路，是把上传当成一条完整的数据生命周期来处理：先接收 $_FILES，再依次校验错误码、文件大小、MIME 类型和扩展名，随后生成服务端专属文件名完成安全落盘，最后把路径、大小、类型和业务归属关系存成记录，方便后续查询、回收和审计。

把上传看成完整数据流，而不是一行简单的保存代码

很多老项目里的上传代码写得非常粗放：拿到 $_FILES['file']，随便拼个存储文件夹，直接调用 move_uploaded_file()，然后就把路径写进数据库。这个流程虽然短，但出了问题根本没法排查：到底是浏览器没把文件传上来、文件体积超出限制、格式不符合要求、文件夹没有写入权限，还是后面写数据库的时候出错了？

更推荐把上传流程拆成几个边界清晰的独立状态。每个状态只负责一件事，操作失败的时候也能返回明确的错误原因。

入口校验优先从上传错误码开始

$_FILES 里本身已经自带了上传错误码，不少开发者会直接忽略它，转头就去读取 tmp_name。这一步校验完全没必要省，因为文件大小超出 upload_max_filesize、表单上传字段缺失、上传中途中断这类异常，都会先反映在错误码里。

这里不需要急着执行保存操作，先确认「这确实是一份通过合法 HTTP 请求上传生成的临时文件」。入口越早把异常请求挡住，后面的业务代码逻辑就越干净。

扩展名、MIME 类型和文件大小要组合校验

只校验扩展名的防护非常脆弱，攻击者完全可以把可执行文件的后缀改成 .jpg 来绕过检测。只信任浏览器提交的 type 同样不靠谱，因为这个值完全可以由客户端随意篡改。更可靠的方案是由服务端自己读取文件内容判断真实 MIME 类型，同时把允许上传的范围写成固定白名单。

 $maxSize) {
        throw new RuntimeException('文件大小超出限制');
    }

    $finfo = new finfo(FILEINFO_MIME_TYPE);
    $mime = $finfo->file($file['tmp_name']);

    $allowed = [
        'image/jpeg' => 'jpg',
        'image/png'  => 'png',
        'image/webp' => 'webp',
    ];

    if (!isset($allowed[$mime])) {
        throw new RuntimeException('文件类型不在允许范围内');
    }

    return [$mime, $allowed[$mime]];
}

如果是头像、封面图、商品配图这类明确的图片场景，白名单范围应该设置得更窄。不要为了所谓的兼容性把上传入口做成什么文件都能接收，业务场景越明确，规则就越好定义，安全边界也会越清晰。

文件落盘时不要信任用户提交的原始文件名

用户上传的原始文件名可以单独存到数据库里做页面展示用，但绝对不能直接作为服务器上的存储路径。文件名里可能包含空格、特殊控制字符、同名覆盖风险，甚至是用来绕过路径边界的特殊片段。由服务端统一生成文件名会省心很多。

 $target,
        'name' => $name,
    ];
}

生产环境部署时还要额外考虑文件夹权限和访问控制。公开类图片可以放到静态资源路径下，但最好只对外暴露经过规则处理后的访问地址；合同、证件、批量导入表格这类敏感文件，不建议直接放在可直接访问的公开路径下，应该通过带鉴权逻辑的下载接口校验权限后再返回内容。

存储记录和清理策略同样不能忽视

上传流程到文件落盘并不算结束。数据库里至少要记录关联的业务对象、服务端存储路径、原始文件名、MIME 类型、文件大小、上传操作人和文件状态字段。后续做列表展示、权限判断、容量统计、过期清理这些操作时，才有明确的数据依据。

 $userId,
    'origin_name' => $file['name'],
    'stored_name' => $saved['name'],
    'stored_path' => $saved['path'],
    'mime' => $mime,
    'size' => $file['size'],
    'status' => 'ready',
];

清理策略也要提前规划好。比如上传成功但后续业务表保存失败时，已经落盘的文件要不要立刻删除；用户替换头像后，旧的头像文件是不是可以延迟一段时间再清理；批量导入任务失败后，原始上传文件最多保留多长时间。把这些规则写成定时任务或者后台清理脚本统一执行，比等到磁盘告警之后再手动翻找零散文件要高效得多。

相关问题

PHP 上传图片只判断后缀名可以吗？

不建议这么做。后缀名只能说明文件名的后缀看起来是图片格式，完全不能证明文件本身内容是安全的。至少要结合真实 MIME 检测、大小限制和业务场景白名单一起校验。

上传文件夹可以放在 public 公开路径下面吗？

普通公开图片可以存放，但要严格控制允许写入的文件类型和对外暴露的访问路径。非公开附件、导入文件、证件类资料更适合放在站点根路径以外的非公开文件夹，通过下载接口鉴权通过后再返回内容。

为什么 move_uploaded_file 执行后返回 false？

常见原因包括临时文件已经不存在、目标存储文件夹没有写入权限、目标文件路径拼接错误、文件不是通过合法 HTTP 上传生成的临时文件。调试的时候先打印出完整存储路径、系统错误码和 is_uploaded_file() 的返回结果，不要不加判断直接重试。

数据库保存失败后对应的上传文件怎么处理？

简单场景可以直接立即删除已经落盘的文件；更复杂的业务场景可以先把文件标记为待清理状态，再由定时任务统一扫描回收。核心是一定要有对应的状态记录，不能让无效文件静默留在磁盘里占空间。