PHP如何处理大文件上传 PHP分片上传与断点续传技术-php教程-PHP中文网

核心解决方案是采用分片上传结合断点续传技术，1. 客户端利用file api将大文件切片并生成唯一标识（如md5）；2. 每个分片携带文件标识、索引等信息上传至服务端；3. 服务端php接收分片并存储于以文件哈希命名的临时目录中；4. 使用数据库或redis持久化记录各分片上传状态；5. 上传前客户端查询已上传分片列表实现断点续传；6. 所有分片上传完成后服务端按序合并文件并清理临时数据；7. 合并时采用流式写入避免内存溢出，最终返回完整文件路径，整个过程有效规避了php上传限制并提升了稳定性和用户体验。

PHP如何处理大文件上传 PHP分片上传与断点续传技术

处理PHP大文件上传，尤其是面对动辄几百兆甚至几个G的文件时，传统的上传方式确实会遇到瓶颈。核心的解决方案，或者说我个人认为最靠谱的路径，就是采用分片上传（Chunked Upload）结合断点续传（Resumable Upload）技术。这不仅仅是技术上的选择，更是对用户体验和系统稳定性的一个根本性提升。它将一个庞大的文件拆解成若干个小块，逐一上传，并记录上传进度，即使网络中断或浏览器关闭，也能在下次连接时从上次中断的地方继续。

解决方案

要实现PHP的大文件分片上传与断点续传，这通常是一个客户端（浏览器/JS）与服务端（PHP）协作的工程。

客户端的职责：

立即学习“PHP免费学习笔记（深入）”；

文件切片：利用HTML5的
```
File
```
登录后复制
登录后复制
API，特别是
```
slice()
```
登录后复制
方法，将用户选择的大文件分割成固定大小（比如1MB、5MB）的块。
唯一标识：为整个文件生成一个唯一的标识符，比如文件的MD5哈希值。这个标识符是服务端识别文件、管理分片的核心。
分片上传：逐个或并发地将这些小文件块通过XMLHttpRequest或Fetch API发送到服务器。每个请求除了包含文件块本身，还需要带上文件唯一标识、当前分片索引、总分片数等信息。
进度查询：在开始上传前，客户端会向服务器查询该文件已上传的分片列表，以便从正确的断点开始续传。
上传状态管理：客户端需要维护上传进度条，并在每个分片上传成功后更新状态。

服务端的职责（PHP）：

接收分片：PHP脚本负责接收每个上传过来的文件块。由于是小文件，这避免了
```
upload_max_filesize
```
登录后复制
登录后复制
和
```
post_max_size
```
登录后复制
登录后复制
的限制。
临时存储：将接收到的每个分片存储在一个临时目录中。这个目录通常以文件的唯一标识（MD5）命名，确保不同文件的分片不会混淆。每个分片文件也应以其索引命名，方便后续排序和合并。
状态记录：使用数据库（如MySQL）或键值存储（如Redis）来记录每个文件的上传进度。例如，可以存储文件唯一标识、已上传的分片索引列表、文件总大小、总分片数等。这对于断点续传至关重要。
分片校验（可选但推荐）：对每个上传的分片进行校验，比如计算分片内容的哈希值并与客户端传来的哈希值比对，确保数据完整性。
分片合并：当所有分片都成功上传并记录后，PHP脚本触发合并操作。这涉及到按顺序读取所有临时分片文件，并将它们的内容追加写入到一个最终的目标文件中。合并完成后，删除临时分片文件和目录。
错误处理与响应：及时向客户端返回上传状态，包括成功、失败、需要重传的分片等信息。

为什么传统PHP上传方式不适合大文件？

传统的PHP文件上传，说白了，就是浏览器一次性把整个文件通过HTTP POST请求发给服务器，然后PHP的

move_uploaded_file()

登录后复制

函数处理这个临时文件。听起来简单直接，但它在处理大文件时，很快就会暴露出一些固有的缺陷。

首先，最直观的就是PHP配置的限制。

php.ini

登录后复制

里有几个关键参数：

upload_max_filesize

登录后复制

、

post_max_size

登录后复制

和

max_execution_time

登录后复制

。默认情况下，这些值通常很小，比如

2M

登录后复制

或

8M

登录后复制

。当你尝试上传一个几百兆的文件时，第一个遇到的就是文件大小超限的错误。就算你把这些值调得很高，比如

2G

登录后复制

，那么问题又来了：PHP在处理上传时，可能会尝试将整个文件加载到内存中（虽然不总是这样，但元数据和某些操作仍然可能消耗大量内存），这很快就会触及

memory_limit

登录后复制

的上限。更要命的是，上传一个大文件可能需要很长时间，这又会触发

max_execution_time

登录后复制

，导致脚本执行超时，上传失败。

其次，网络环境的不稳定性是另一个大敌。我们的网络连接不是百分之百可靠的，尤其是在移动设备上或者跨国传输时。一个几百兆的文件，在上传过程中如果遇到网络波动、连接中断，那么整个上传过程就得从头再来。这对于用户来说，无疑是极度糟糕的体验，耗时耗力，而且挫败感十足。用户可能已经等了半小时，结果功亏一篑，谁能接受呢？

再者，用户体验的缺失。传统上传方式通常没有内置的进度条。用户上传一个大文件时，界面可能长时间没有响应，他们不知道上传进行到哪一步了，有没有卡住，甚至是否还在上传。这种“黑箱”操作很容易让用户感到焦虑和不确定。

所以，与其说是PHP本身处理不了大文件，不如说是在HTTP协议和PHP传统处理模式下，单次传输的“全有或全无”策略，在大文件面前显得力不从心。

PHP分片上传的核心实现思路是什么？

分片上传的核心思想，就像把一头大象装进冰箱，得先切片，再分批装进去。

在客户端，这通常依赖于JavaScript和HTML5的

File

登录后复制

API。

文件选择与切片：当用户选择一个大文件后，JavaScript会获取到这个文件对象。利用
```
File.prototype.slice(start, end)
```
登录后复制
方法，可以非常方便地将文件“切”成指定大小的二进制块（Blob）。比如，一个100MB的文件，我可以设定每块1MB，那么就会切成100个小块。
唯一标识生成：为了让服务器知道这些小块属于哪个大文件，客户端通常会计算整个文件的MD5、SHA1或其他哈希值。这个哈希值就是文件的“身份证”。如果文件内容不变，它的哈希值就不会变，这对于断点续传和秒传（如果服务器已经有了这个文件，就不用再上传了）都非常关键。
并发与顺序：客户端可以根据网络情况选择是并发上传多个分片，还是顺序上传。通常，为了效率，会限制一定的并发数。每个分片通过
```
FormData
```
登录后复制
对象封装，然后用
```
XMLHttpRequest
```
登录后复制
或
```
fetch
```
登录后复制
发送到服务器。请求中除了分片数据，还会带上文件哈希、当前分片索引（
```
chunkIndex
```
登录后复制
）、总分片数（
```
totalChunks
```
登录后复制
）等元数据。

在服务器端（PHP），这块的逻辑相对复杂一些，但思路清晰：

接收分片：PHP脚本会接收到客户端发送过来的每个小分片。因为是小文件，它们会正常地被PHP处理，存放在
```
$_FILES['your_chunk_field']['tmp_name']
```
登录后复制
中。
临时目录管理：我通常会创建一个以文件哈希命名的临时目录，比如
```
/tmp/uploads/md5_of_file/
```
登录后复制
。每个接收到的分片，我会将其
```
move_uploaded_file()
```
登录后复制
登录后复制
到这个临时目录中，并以其分片索引作为文件名（例如
```
0.chunk
```
登录后复制
,
```
1.chunk
```
登录后复制
）。这样做的好处是，即使服务器重启，只要临时目录还在，分片数据就还在。
分片状态记录：这是断点续传的关键。我会在数据库中建立一个表，或者使用Redis这样的内存数据库，来记录每个文件（通过其哈希识别）已经成功上传了哪些分片。比如，一个JSON字符串存储已上传分片的索引数组，或者为每个分片单独记录一个状态。
合并逻辑：当客户端通知所有分片都已上传完毕，或者服务器通过查询发现所有分片都已到位时，PHP脚本就会触发合并操作。这通常是一个循环：按分片索引的顺序，逐个读取临时目录中的分片文件，然后使用
```
file_put_contents($finalFilePath, file_get_contents($chunkFilePath), FILE_APPEND)
```
登录后复制
或者更底层的
```
fopen()
```
登录后复制
以追加模式(
```
'ab'
```
登录后复制
)打开最终文件，将分片内容写入。合并完成后，清理掉临时分片文件和目录，更新数据库中文件的最终状态。

这里需要注意的是，合并时如果文件非常大，直接

file_get_contents

登录后复制

可能会再次导致内存问题。更稳妥的方式是使用

fread

登录后复制

和

fwrite

登录后复制

，以流式方式处理。

// 简化版PHP分片接收和记录逻辑
// 实际应用中需要更严谨的错误处理、安全校验和并发控制

if ($_SERVER['REQUEST_METHOD'] === 'POST' && isset($_FILES['chunk'])) {
    $fileHash = $_POST['file_hash'] ?? '';
    $chunkIndex = (int)($_POST['chunk_index'] ?? 0);
    $totalChunks = (int)($_POST['total_chunks'] ?? 1);
    $fileName = $_POST['file_name'] ?? 'uploaded_file'; // 最终文件名

    if (empty($fileHash) || !isset($_FILES['chunk'])) {
        http_response_code(400);
        echo json_encode(['code' => 400, 'message' => '参数缺失或文件未上传']);
        exit;
    }

    $uploadDir = 'uploads/temp/'; // 临时上传根目录
    $tempFileDir = $uploadDir . $fileHash . '/'; // 特定文件的临时目录

    if (!is_dir($tempFileDir)) {
        if (!mkdir($tempFileDir, 0777, true)) {
            http_response_code(500);
            echo json_encode(['code' => 500, 'message' => '无法创建临时目录']);
            exit;
        }
    }

    $chunkFilePath = $tempFileDir . $chunkIndex . '.chunk';

    // 移动上传的分片到临时目录
    if (move_uploaded_file($_FILES['chunk']['tmp_name'], $chunkFilePath)) {
        // 记录分片状态到数据库或Redis
        // 假设这里有一个函数来更新分片状态
        // updateChunkStatus($fileHash, $chunkIndex, $totalChunks, $fileName);

        // 检查是否所有分片都已上传
        $uploadedCount = count(glob($tempFileDir . '*.chunk'));
        if ($uploadedCount == $totalChunks) {
            // 所有分片已上传，开始合并
            $finalDestination = 'uploads/final/' . $fileName; // 最终文件存储路径
            $outputFile = fopen($finalDestination, 'ab'); // 追加模式打开或创建

            if ($outputFile === false) {
                http_response_code(500);
                echo json_encode(['code' => 500, 'message' => '无法创建最终文件']);
                exit;
            }

            for ($i = 0; $i < $totalChunks; $i++) {
                $currentChunkPath = $tempFileDir . $i . '.chunk';
                if (file_exists($currentChunkPath)) {
                    $chunkContent = file_get_contents($currentChunkPath);
                    fwrite($outputFile, $chunkContent);
                    unlink($currentChunkPath); // 合并后删除分片
                } else {
                    // 理论上不应该发生，除非有分片丢失
                    fclose($outputFile);
                    http_response_code(500);
                    echo json_encode(['code' => 500, 'message' => '分片缺失，合并失败']);
                    exit;
                }
            }
            fclose($outputFile);
            rmdir($tempFileDir); // 删除临时文件目录

            // 更新数据库中文件状态为已完成
            // markFileAsComplete($fileHash, $finalDestination);

            echo json_encode(['code' => 200, 'message' => '文件上传并合并成功', 'file_path' => $finalDestination]);
        } else {
            echo json_encode(['code' => 200, 'message' => '分片上传成功', 'uploaded_count' => $uploadedCount]);
        }
    } else {
        http_response_code(500);
        echo json_encode(['code' => 500, 'message' => '分片移动失败']);
    }
} else {
    // 处理客户端查询已上传分片的请求
    if ($_SERVER['REQUEST_METHOD'] === 'GET' && isset($_GET['file_hash'])) {
        $fileHash = $_GET['file_hash'];
        $tempFileDir = 'uploads/temp/' . $fileHash . '/';
        $uploadedChunks = [];
        if (is_dir($tempFileDir)) {
            $files = glob($tempFileDir . '*.chunk');
            foreach ($files as $file) {
                $chunkIndex = (int)basename($file, '.chunk');
                $uploadedChunks[] = $chunkIndex;
            }
        }
        echo json_encode(['code' => 200, 'uploaded_chunks' => $uploadedChunks]);
        exit;
    }
    http_response_code(405);
    echo json_encode(['code' => 405, 'message' => '不支持的请求方法或缺少参数']);
}

登录后复制

如何实现PHP断点续传功能？

断点续传，顾名思义，就是从上次中断的地方继续。它的实现，是建立在分片上传的基础之上的，关键在于状态的持久化和查询。

设想一下，你正在上传一个大文件，突然网络断了。当你重新连接或者刷新页面时，你肯定不希望从头再来。

实现断点续传的步骤是这样的：

客户端查询已上传状态：
- 在开始上传任何分片之前，客户端（通常是JavaScript）会首先向服务器发送一个查询请求。这个请求会带上文件的唯一标识（比如MD5哈希值）。
- “嘿，服务器，对于这个文件（MD5: XXX），你已经收到哪些分片了？”
服务器响应已上传状态：
- 服务器接收到查询请求后，会去查找它之前存储的关于这个文件的上传进度记录。
- 如果使用数据库，它会查询对应文件哈希的记录，返回一个已成功接收的分片索引列表。
- 如果使用Redis，它可能存储一个Set，里面包含了所有已上传的分片索引。
- “哦，这个文件啊，我这里已经有分片0、1、2、5、6了。”服务器会把这个列表返回给客户端。
客户端根据状态调整上传策略：
- 客户端拿到服务器返回的已上传分片列表后，会剔除掉这些已上传的分片。
- 然后，它会从剩余的、未上传的分片中，选择下一个分片开始上传。
- 如果客户端本地也有缓存的上传进度（比如LocalStorage），它会先对比本地和服务器的状态，以服务器的状态为准（因为服务器的数据更权威）。
服务器持续更新状态：
- 每当服务器成功接收到一个分片，它就会立即更新其内部的进度记录（数据库或Redis），标记这个分片为“已完成”。
- 这样，即使在合并完成前再次中断，服务器也知道哪些分片已经到位了。

关键点在于：

唯一文件标识：文件的MD5哈希值是核心。它确保了服务器能够准确地识别和管理每个大文件的分片，即使是同一个文件被不同用户上传，或者同一个用户多次尝试上传。
持久化存储：上传进度必须被持久化存储，不能只存在于内存中。数据库（如MySQL）或键值存储（如Redis）都是很好的选择。Redis因为其高性能和对列表、集合等数据结构的支持，在大文件上传场景中非常受欢迎，可以用来存储每个文件已上传的分片索引集合。
原子性操作：在更新分片状态时，确保操作的原子性，避免并发问题导致数据不一致。

通过这种机制，无论上传过程被中断多少次，只要文件标识不变，客户端都能向服务器查询当前进度，并从上次中断的地方无缝续传，极大地提升了用户体验和上传的成功率。

以上就是PHP如何处理大文件上传 PHP分片上传与断点续传技术的详细内容，更多请关注php中文网其它相关文章！