PHP 文件操作怎么做？读取、写入、移动和删除文件的完整思路

PHP 文件操作怎么设计，从读取、写入到移动和删除的工程实践

在 PHP 网站开发中，文件操作并不只是调用几个函数那么简单。配置文件、日志、用户上传文件、静态 HTML、缓存以及临时文件，都可能依赖文件系统。真正容易出问题的地方，也往往不是 file_get_contents() 或 unlink() 本身，而是路径如何确定、多个 PHP 进程同时操作同一个文件时怎么办、写入过程中程序异常退出怎么办，以及用户提交的数据能否直接参与文件路径构造。

因此，设计 PHP 文件操作时，应该把文件系统看成一个需要明确边界和状态管理的存储层，而不是简单的函数集合。

读取文件首先要考虑数据规模和访问方式。

对于配置文件、小型模板或者体积较小的文本文件，可以直接使用 file_get_contents()：

$content = file_get_contents($file);

这种方式代码简单，PHP 会将整个文件读入内存。对于小文件通常没有问题，但如果文件可能达到几十 MB、几百 MB甚至更大，就不能只看代码是否简洁，还需要考虑 PHP 进程的 memory_limit 以及同一台服务器上同时运行多少个 PHP-FPM worker。

需要流式处理时，可以使用 fopen() 配合 fgets() 或 fread()：

$handle = fopen($file, 'rb');

while (($line = fgets($handle)) !== false) {
// 处理当前行
}

fclose($handle);

这里的关键并不是“fopen() 比 file_get_contents() 高级”，而是两者对应不同的数据处理模型。一次性读取适合小文件，而流式读取适合需要控制内存占用的大文件处理。

如果处理的是二进制文件，则应该使用二进制模式，例如 rb 和 wb，避免把文件操作简单地限定为文本文件。

写入文件时，真正需要考虑的是覆盖、追加、并发以及写入失败。

最简单的写法是：

$result = file_put_contents($file, $content);

if ($result === false) {
throw new RuntimeException('文件写入失败');
}

默认情况下，这种操作会覆盖原有文件内容。因此，日志等需要持续追加的数据，应使用追加模式：

$result = file_put_contents(
$logFile,
$message . PHP_EOL,
FILE_APPEND | LOCK_EX
);

这里的 LOCK_EX 很重要。当多个 PHP-FPM worker 同时向同一个日志文件写入时，如果没有适当的并发控制，就可能出现写入竞争。对于简单日志追加，独占锁可以降低多个进程同时修改同一文件所带来的问题。

但锁并不能把普通文件变成数据库。高并发环境下，如果大量请求都同步写入一个日志文件，文件锁本身就可能成为竞争点。这种情况下，更合理的方案可能是使用专门的日志系统、集中式日志服务或者其他持久化机制。

文件更新则是另一个容易被忽略的问题。

假设网站需要重新生成一个 HTML 文件。如果直接执行：

file_put_contents($htmlFile, $html);

在文件写入期间，其他请求可能读取到正在变化的文件。对于重要的静态文件，更稳妥的方式通常是先写入临时文件，确认写入成功后，再使用 rename() 完成替换。

例如：

$tmpFile = $htmlFile . '.tmp';

if (file_put_contents($tmpFile, $html) === false) {
throw new RuntimeException('临时文件写入失败');
}

if (!rename($tmpFile, $htmlFile)) {
@unlink($tmpFile);
throw new RuntimeException('文件替换失败');
}

这种设计的意义在于把“生成文件”和“让新文件正式生效”分成两个阶段。对于静态页面生成、配置文件更新等场景，这种模式通常比直接覆盖目标文件更加可靠。

需要注意的是，rename() 并不是简单意义上的“移动文件函数”。它既可以重命名文件，也可以改变文件路径。具体行为还受到操作系统、文件系统以及源目标位置等条件影响。如果源文件和目标文件位于不同文件系统，不能假设 rename() 一定能够完成跨文件系统移动。

在无法直接使用 rename() 完成跨文件系统移动时，可以采用复制后删除：

if (!copy($source, $target)) {
throw new RuntimeException('文件复制失败');
}

if (!unlink($source)) {
throw new RuntimeException('源文件删除失败');
}

但这并不等价于 rename()。复制完成之后再删除源文件，中间存在一个时间窗口。如果程序在复制成功、删除失败之间退出，就可能同时存在两个文件。因此，对于重要数据，还需要根据业务要求设计校验、重试和失败恢复机制。

删除文件使用 unlink()：

if (is_file($file) && !unlink($file)) {
throw new RuntimeException('文件删除失败');
}

这里需要特别注意，unlink() 删除文件并不意味着对磁盘进行物理擦除。对于普通 Web 应用，它通常意味着文件从文件系统目录结构中被删除，但底层存储设备如何处理已经释放的数据属于另一个层面的问题。因此，不应该把 unlink() 描述成“安全彻底擦除”。

目录删除同样不能混淆。rmdir() 只能删除空目录。如果目录中还有文件，需要先处理目录中的内容，再删除目录本身。

真正容易产生安全问题的是路径。

例如：

$file = $_POST['file'];
unlink('/var/www/uploads/' . $file);

这种代码不能直接用于生产环境。攻击者可能通过构造特殊路径，让程序访问预期目录之外的文件。

安全的文件操作应该首先确定应用允许访问的根目录，再对路径进行规范化和边界检查。例如：

$baseDir = realpath(__DIR__ . '/uploads');

$target = realpath($baseDir . '/' . $filename);

if ($target === false || !str_starts_with($target, $baseDir . DIRECTORY_SEPARATOR)) {
throw new RuntimeException('非法文件路径');
}

不过这里还有一个实际问题：realpath() 对不存在的目标文件可能返回 false。因此，对于上传文件、即将创建的新文件等场景，不能简单套用这一种判断方式，而应该分别处理“已经存在的路径”和“准备创建的路径”。

更稳妥的设计通常是不要让用户直接决定服务器上的真实文件名。

例如数据库保存：

id = 1258

实际文件则由服务器生成：

/uploads/1258/8f3a91d2.jpg

用户提交的只是业务对象标识，而不是 /var/www/... 这样的服务器路径。这样可以从架构层面降低路径遍历和任意文件操作的风险。

上传文件尤其应该避免直接使用用户提交的文件名作为最终路径。原始文件名可以作为业务数据保存，但服务器实际存储名称最好由应用生成，并结合允许的扩展名、MIME 类型、文件大小以及上传错误状态进行验证。

文件权限也是文件系统设计的一部分。

PHP 进程能够读取一个文件，不代表它应该拥有修改甚至删除整个目录的权限。Web 应用使用的账户应当只获得完成业务所需要的最低权限。

例如，上传目录可能需要 PHP 写入，但网站程序并不应该因此获得整个网站目录的任意写权限。权限范围过大时，一旦应用层出现文件上传漏洞，攻击者造成的影响也会随之扩大。

对于网站自动生成 HTML 的场景，还应该考虑并发生成。

假设两个 PHP 请求同时重新生成同一个页面：

请求 A → 生成 article-100.html
请求 B → 生成 article-100.html

如果两个请求直接写同一个文件，最终内容取决于两个写入操作的执行过程。解决方案可以是文件锁、任务队列，或者采用“临时文件生成后原子替换”的方式降低竞争。

而当文件数量非常大时，还需要进一步考虑目录结构。例如不要把数十万个文件全部放在同一个目录中，而是按照日期、ID 或哈希值进行分层：

uploads/
2026/
08/
26/
a8/
1258.jpg

这比单纯讨论某一个 PHP 函数更加接近实际生产环境中的文件系统设计。

因此，PHP 文件操作真正需要掌握的不是几十个函数，而是几个核心原则。

读取时，根据文件规模选择一次性读取还是流式读取；写入时，明确覆盖还是追加，并考虑并发；更新重要文件时，优先考虑临时文件加替换；移动文件时区分 rename() 与复制后删除的语义；删除文件时明确操作范围，不要把 unlink() 当成物理擦除；处理用户输入时，不让用户直接控制服务器文件路径；处理上传文件时，将业务文件名与物理存储路径分离。

当 PHP 应用开始涉及静态页面生成、文件上传、日志系统、缓存以及定时任务时，文件操作实际上已经成为应用架构的一部分。此时，代码是否能够调用成功只是最基础的问题，更重要的是明确文件生命周期、访问边界、并发行为以及失败后的恢复方式。

这也是 PHP 文件操作从“会用函数”走向“能够进行工程设计”的分界线。