PHP 上传文件怎么实现？从 HTML 表单到服务器保存一步一步完成

文件上传看起来只是一个HTML表单加一个PHP脚本，但真正进入生产环境后，上传功能实际上涉及HTTP请求、PHP运行时、临时文件、权限控制、文件类型验证、文件命名、存储位置以及后续访问控制多个环节。一个可以把文件从浏览器保存到服务器的代码，只能算“上传功能跑通”，并不意味着它已经具备生产环境需要的安全性。 最基本的HTML上传表单需要使用POST方法，并将enctype设置为multipart/form-data。如果缺少这个属性，浏览器不会按照文件上传所需要的multipart格式提交文件，PHP也就无法按照正常方式在$_FILES中获得上传文件。

上传

这里的name="file"决定了PHP中的数组键名，因此服务端可以通过$_FILES['file']读取这个上传字段。多个文件上传时，则需要根据HTML中的multiple属性和name命名方式处理对应的数组结构。 浏览器提交文件后，PHP不会直接把这个文件永久保存到目标目录。通常情况下，PHP首先把上传内容接收到服务器临时目录，并在$_FILES中提供文件名、临时路径、大小、错误代码等信息。应用程序需要检查上传状态，然后决定是否接受这个文件。 最基本的处理逻辑可以写成： if ($_SERVER['REQUEST_METHOD'] !== 'POST') { http_response_code(405); exit('Method Not Allowed'); } if (!isset($_FILES['file'])) { http_response_code(400); exit('No file uploaded'); } $file = $_FILES['file']; if ($file['error'] !== UPLOAD_ERR_OK) { http_response_code(400); exit('Upload failed: ' . $file['error']); } $tmpPath = $file['tmp_name']; if (!is_uploaded_file($tmpPath)) { http_response_code(400); exit('Invalid uploaded file'); } UPLOAD_ERR_OK表示PHP层面的文件上传已经成功完成。其他错误代码则可能对应超过PHP允许的文件大小、超过POST请求限制、临时目录错误、部分上传或者没有选择文件等情况。 is_uploaded_file()可以用于确认指定文件是否由PHP通过HTTP POST上传产生。它对于防止应用程序把服务器上的任意本地文件误当成上传文件进行处理有帮助，但不能把它理解成完整的文件安全验证。一个文件确实来自HTTP上传，并不意味着它是安全的。 文件上传的大小限制应该分成两个层次理解。PHP中的upload_max_filesize限制单个上传文件大小，而post_max_size限制整个POST请求能够接收的数据规模。因此，如果需要允许上传10MB文件，不能只盯着upload_max_filesize，还应该确保POST请求整体限制足以容纳文件以及multipart请求中的其他数据。 例如： upload_max_filesize = 10M post_max_size = 12M 实际数值应该根据应用需求决定，而且还需要考虑Web服务器、反向代理、WAF或者CDN是否存在另外的请求大小限制。如果Nginx、Apache或者上游代理设置了更小的限制，PHP配置再大也无法突破前面的限制。 应用程序还应该设置自己的业务大小限制。例如系统规定图片最大5MB，那么即使PHP允许上传20MB，也应该在应用层主动拒绝超过5MB的文件。 $maxSize = 5 * 1024 * 1024; if ($file['size'] > $maxSize) { http_response_code(413); exit('File too large'); } 这里的$file['size']可以用于业务层的文件大小检查，但它不是服务器整体上传限制的替代品。PHP运行时限制和应用业务限制应该同时存在。 文件类型验证则更加容易出错。原稿使用$_FILES['type']判断MIME类型，这种做法不能作为安全验证依据，因为这个字段受到客户端提交内容影响。攻击者可以使用自己构造的请求，而不是依赖正常浏览器提供的类型信息。 扩展名检查也不能单独作为文件真实性验证。比如攻击者完全可以把恶意内容命名成photo.jpg。因此生产环境应该采用允许列表，并结合服务器端的实际内容检测。 对于普通图片上传，可以先检查扩展名： $allowedExtensions = [ 'jpg', 'jpeg', 'png', 'webp' ]; $extension = strtolower( pathinfo($file['name'], PATHINFO_EXTENSION) ); if (!in_array($extension, $allowedExtensions, true)) { http_response_code(400); exit('Unsupported file type'); } 但到这里仍然不能认为文件是合法图片。下一步应该使用服务器端的文件类型检测机制判断实际内容。例如PHP的Fileinfo扩展可以读取文件内容特征，而不是简单相信浏览器提供的MIME值。 $finfo = new finfo(FILEINFO_MIME_TYPE); $mime = $finfo->file($tmpPath); $allowedMimeTypes = [ 'image/jpeg', 'image/png', 'image/webp' ]; if (!in_array($mime, $allowedMimeTypes, true)) { http_response_code(400); exit('Invalid file type'); } 对于图片应用，还可以进一步进行实际解码验证。也就是说，服务器不仅检查文件名和MIME，还尝试使用图像处理库打开它。如果应用确实需要重新处理图片，可以在验证后重新编码成目标格式，并把重新生成的文件作为最终存储对象。 这比读取文件开头几个字节，然后寻找GIF、PNG或者其他固定字符串可靠得多。简单的Magic Number检查只能作为其中一个辅助信号，不能代替完整的文件验证。 图片还应该考虑像素尺寸，而不仅仅是压缩后的文件大小。一个压缩文件可能只有几MB，但解码后却包含极大的像素矩阵。如果服务器直接对这种图片执行缩放、旋转或者缩略图生成，可能造成大量内存和CPU消耗。因此生产系统可以对图片宽度、高度、总像素数设置上限。 文件命名也是上传系统的重要安全边界。不要直接把用户提交的原始文件名作为服务器最终文件名： $targetPath = $uploadDir . $file['name']; 这样可能造成文件覆盖、特殊字符处理问题、路径相关风险以及后续访问管理混乱。 basename()可以减少路径字符串处理中的一部分问题，但它并不能让用户提供的文件名变成安全的服务器文件名。因此，生产环境更合理的做法是由服务器重新生成文件名。 例如： $randomName = bin2hex(random_bytes(16)) . '.' . $extension; $targetPath = $uploadDir . $randomName; random_bytes()适合生成密码学安全的随机数据。相比之下，uniqid()主要根据时间生成标识符，并不是为安全随机文件名设计的。 也没有必要使用md5_file()作为随机文件名方案。文件内容哈希可以用于去重或者内容寻址，但它和随机不可预测的对象名称解决的是不同问题。如果两个用户上传完全相同的文件，基于内容生成的名字可能相同，这有时是优点，有时却可能造成业务逻辑上的覆盖和权限问题。 最终文件还应该使用服务器端确定的扩展名和随机名称保存。例如： $uploadDir = '/var/www/private_uploads/'; if (!is_dir($uploadDir)) { mkdir($uploadDir, 0750, true); } $randomName = bin2hex(random_bytes(16)) . '.' . $extension; $targetPath = $uploadDir . $randomName; if (!move_uploaded_file($tmpPath, $targetPath)) { http_response_code(500); exit('Failed to save file'); } 这里的存储路径最好不要直接放在Web DocumentRoot下面。对于需要权限控制的文件，将上传内容放在Web服务器无法直接通过URL访问的目录中通常更加安全。应用程序在完成认证和授权后，再决定是否允许用户下载相应文件。 如果业务必须把文件放在Web目录下，那么上传目录必须明确禁止脚本执行。尤其是允许上传的文件类型比较复杂时，不能因为扩展名过滤看起来有效，就认为上传目录可以安全执行PHP、CGI或者其他服务器端脚本。 文件权限同样需要遵循最小权限原则。上传目录不应该为了“解决权限问题”直接设置成777。Web服务器运行账户只应该拥有完成上传所需要的权限，其他用户和进程不应该获得不必要的写入能力。 文件保存之后，如果应用还需要把文件信息写入数据库，数据库中通常应该保存对象ID、随机文件名、原始文件名、文件大小、MIME类型、上传者、所属租户、创建时间以及存储状态等信息。原始文件名并非不能保存，它可以作为用户界面显示信息，但不能把它当成服务器实际存储路径。 对于SaaS系统，上传记录还应该与租户和用户建立明确的所有权关系。例如一个用户请求下载文件时，不能仅凭文件ID就直接返回文件。API需要确认当前身份属于正确租户，并且该用户对指定文件拥有访问权限。 因此，文件ID本身不能等同于授权。即使文件名完全随机，也只是降低了被猜测的可能性，并不能替代权限控制。 上传接口还应该考虑CSRF。对于依赖浏览器Cookie进行身份认证的Web应用，文件上传通常属于需要考虑CSRF保护的状态改变操作。可以使用CSRF Token等机制验证请求来源。对于纯API场景，则应根据实际认证方式和跨域架构进行设计。 CORS则是另外一个概念。如果前端页面和上传API位于不同Origin，浏览器可能需要CORS响应策略。但“使用AJAX上传”并不意味着服务器必须返回： Access-Control-Allow-Origin: * 尤其是涉及用户身份Cookie或者敏感数据时，开放所有Origin通常并不是合理的生产配置。应该根据实际前端Origin、认证方式以及是否需要凭证来设计CORS策略。 AJAX上传的价值主要在于改善用户体验。使用fetch()或者XMLHttpRequest可以让页面不必完整刷新，并能够实现上传状态、错误提示以及进度显示。它不会改变服务器端的安全要求。无论请求来自传统HTML表单还是JavaScript，服务器都必须重新验证文件。 大文件上传则需要另外的架构。对于几十MB、几百MB甚至GB级文件，单纯依赖普通PHP POST上传可能并不是最佳方案。可以根据业务需求设计分块上传、断点续传、对象存储直传或者专门的上传服务。 PHP的上传进度机制可以帮助应用获取某些上传状态，但它并不等于完整的大文件分块上传系统。真正的分块上传通常需要客户端把文件拆分成多个块，服务器保存块状态，并在所有块完成后进行合并和完整性验证。 并发上传也不能简单理解成“使用flock()就能防止文件覆盖”。如果每个上传请求都使用服务器随机生成的唯一对象名称，本身就已经大幅降低了覆盖风险。真正需要锁的地方取决于业务，例如多个请求同时修改同一个文件记录、合并同一个分片文件或者更新同一个上传任务状态时，才需要针对具体资源设计锁、事务或者幂等机制。 临时文件的管理也应该交给PHP运行时和操作系统的正常机制处理。upload_tmp_dir用于指定PHP上传临时文件目录，但它不是应用程序自己的永久文件存储区。应用应该及时完成验证和转存，不要把临时文件当成长期资源。系统层面还需要保证临时目录具备足够空间，并监控磁盘使用情况。 如果服务器磁盘被上传文件耗尽，即使PHP代码本身没有漏洞，整个网站也可能受到影响。因此生产环境除了限制单文件大小，还应该考虑用户、租户和IP级别的上传频率与存储配额。 日志同样需要记录，但不应该把完整API Key、Session Cookie或者Bearer Token写入日志。上传日志可以记录请求时间、用户ID、租户ID、文件对象ID、文件大小、检测结果、最终状态以及错误类型。原始文件名是否记录则需要根据隐私和业务需求决定。 一个比较完整的生产级PHP上传流程，可以理解为：用户首先通过认证进入上传接口，服务器检查CSRF或相应的API认证机制，然后检查上传错误和业务大小限制，再根据允许列表检查扩展名和实际文件类型；对于图片等特定文件，再进行解码、尺寸和资源消耗检查；验证通过以后由服务器生成随机文件名，将文件移动到隔离的存储目录，并把对象信息写入数据库；最后通过日志记录结果，并由后续下载接口执行独立的身份认证和授权。 这里有一个很容易被忽略的安全边界：上传安全和下载安全是两个问题。一个文件上传时没有恶意代码，并不意味着所有用户都应该能够访问它。上传接口负责判断“能不能保存”，下载接口则负责判断“谁可以读取”。在多租户SaaS中，两套权限都必须独立存在。 对于图片、PDF、Office文档、压缩包等不同文件类型，也不能采用一套简单规则解决所有问题。图片可以进行解码和重新编码，PDF需要考虑解析器风险，Office文件可能涉及宏和外部资源，压缩包还要考虑压缩炸弹、嵌套文件以及解压后的总大小。因此，上传系统越复杂，就越应该把“文件接收”“文件验证”“文件处理”和“文件提供”拆成不同阶段。 PHP文件上传真正值得投入精力的地方，并不是把move_uploaded_file()写出来，而是限制服务器到底接受什么、文件最终放在哪里、谁可以读取以及恶意请求出现以后系统会怎样处理。HTML表单只是入口，$_FILES只是PHP提供的数据结构，move_uploaded_file()只是完成文件移动的工具。生产环境的安全性来自整个上传链路的约束，而不是某一个函数。 只要把认证、权限、大小限制、类型允许列表、服务器端内容检测、资源限制、随机命名、隔离存储、脚本执行限制、租户隔离、日志和限流这些环节同时考虑进去，一个PHP文件上传接口才从“能够上传文件”进入了可以用于实际SaaS和Web应用的工程实现。