PHP大文件分片上传方案：前端切片、后端合并与断点续传实战

大文件上传这件事，PHP开发者迟早都会撞上。默认的PHP配置只允许传2MB左右，就算你调大 upload_max_filesize，碰到几百MB甚至几个GB的文件，也会因为超时、内存爆掉、服务器被卡死而翻车。我见过太多人上来就调参数，结果就是治标不治本。真正能稳定可用的方案，是用前端把文件切开，一块一块传，最后在PHP端合起来——也就是分片上传。这篇内容就是围绕这个思路，给出可实际落地的跨平台示例代码，以及我踩坑之后的排查经验，适合所有用PHP做Web上传功能的开发者参考。

1. 项目背景与方案选型思路

1.1 为什么大文件上传这么难

先聊聊痛点。单个大文件通过HTTP POST一次性上传时，会遇到三个绕不过去的坎。第一是服务器限制，Nginx或Apache默认都有限制请求体大小，PHP也有 upload_max_filesize 和 post_max_size，这两个参数必须同时调大，否则文件根本传不上去。第二是执行时间，PHP默认 max_execution_time=30，如果上传一个1GB的文件，即使网速正常，也很容易超过30秒，脚本被强制终止。第三是内存，PHP在接收上传文件时，文件默认存储到临时目录，但如果你对上传内容做额外的处理，比如读取到内存验证，容易触发 memory_limit。

所以，不是PHP不能传大文件，而是传统单文件上传的方式在技术上就有天花板。你把配置调到足够大，比如允许传10GB，但用户的网络一旦波动，整个请求失败就得重来，体验非常差。这也是为什么现在的网盘、SaaS系统普遍采用分片上传——把大文件切成固定大小的块，每块独立上传，失败后只重传那一块。

1.2 跨平台到底在跨什么

“跨平台”这个词大家都爱讲，但落到上传场景里，很多人忽略了细节。对前端来说，不同的操作系统和浏览器之间，切片API的兼容性是个问题，好在这个问题已经基本解决，现代浏览器都支持HTML5 File API。对后端来说，PHP作为服务端脚本，本身可以跑在Windows、Linux、macOS上，不同系统的路径分隔符、文件名编码规则都不一样。如果你在代码里写死 / 作为路径分隔符，在Windows上可能出问题；如果你不处理中文文件名，在Linux服务器上传到带中文名的文件，可能会乱码。

真正意义上的跨平台，不是说代码在哪个系统上都能跑那么简单，而是要确保前端切片、上传、后端接收、合并这一整套流程，在操作系统和浏览器之间没有隐藏的兼容性坑。我通常的做法是：前端只用原生JavaScript的 File.slice() 方法，后端用PHP标准文件函数，再加上一套完整的命名和路径处理逻辑，这样无论用户用的是Mac还是Windows，服务器是Linux还是Windows，都能稳定工作。

1.3 技术方案选型：分片上传 + 服务端合并

综合来看，我最终选定的方案是：前端利用 File.slice() 将文件切割成指定大小的分片，比如每个分片2MB到10MB，然后用 XMLHttpRequest 或 fetch 将分片逐个发送到PHP后端。后端收到分片后，先存储到一个临时目录，记录当前已上传的分片数，当所有分片都上传完毕后，PHP再按顺序读取这些分片并合并成完整文件。

这个方案的优势很明显：第一，分片大小可以控制，规避了服务器对单次请求体的大小限制；第二，支持断点续传，前端可以记录已上传的分片，下次继续；第三，对服务器内存压力小，PHP处理每个分片时只需要操作最多几MB的数据，不会造成内存溢出。当然，它也有代价：需要前后端配合，代码量比直接上传多一点，还会产生临时文件。但这些代价完全在可控范围内，比用户体验翻车要好得多。

2. 核心实现：前端分片与上传流程

2.1 前端如何利用File API进行文件切片

前端是分片上传的第一环，核心就是 File.slice() 方法。假设一个文件是500MB，我们定义每个分片大小为5MB，那么切片总数就是 Math.ceil(file.size / chunkSize)。每个分片对应 file.slice(start, end)，返回一个Blob对象，我们可以把它放到 FormData 里，再用 XMLHttpRequest 发送。注意，Blob 对象也可以直接作为二进制数据发送，但放到 FormData 里更便于携带文件名、索引等元信息。

切片大小需要根据实际场景调整。我常用的经验值：普通Web上传用2MB到10MB；内网环境下可以加大到20MB；移动网络环境下建议2MB，因为网络不稳定，分片太小会导致请求次数过多，分片太大又容易失败。切片总数最好控制在几百个以内，否则服务器端管理临时文件的压力会很大，而且索引容易混乱。

这里有一个很多人忽略的点：切片不是切的越多越好。假设一个10GB的文件，分片1MB，就会有10240个分片，光是HTTP请求的开销就很大，而且PHP端会把临时目录塞满，容易把inode耗尽。所以，要提前判断文件大小，动态调整分片大小，让总分片数控制在200个以内。我的做法是：文件小于1GB用5MB分片，1GB以上用10MB分片，5GB以上用20MB分片。这个策略实测下来比较平衡。

2.2 上传分片时的进度与并发控制

分片上传的过程中，我们通常不会挨个串行上传，那样太慢。但如果把所有分片一次性全部并发发送，服务器可能会扛不住，因为每个请求都会在PHP里创建临时文件。我的建议是：实现一个并发队列，控制同时上传的分片数，比如并发3个或5个。这样既能提升速度，又不会给服务器造成太大压力。

代码上，可以用一个 async 循环来实现简单的并发控制。先拿到所有分片，然后维护一个“当前正在上传”的数组，每完成一个就补充一个，直到所有分片都上传完毕。每个分片上传完成后，还要更新进度条，进度值就是已完成分片数除以总分片数。另外，上传失败的分片要自动重试，我一般设置最多重试3次，3次都失败就给用户提示，让用户手动点击重试。

还有一个很实用的做法：在分片上传前，先向后端发送一个“检测”请求，告诉后端我们准备上传文件名和文件大小。后端可以检查是否已经存在完整文件（秒传），或者检查哪些分片已经上传过（断点续传）。这个检测接口能显著提升体验，尤其在弱网环境下，用户不需要从头再传。

2.3 断点续传与秒传的实现思路

断点续传的本质是：前端在本地记录已上传的分片索引，比如用 localStorage 或内存变量。当页面刷新或上传中断后，重新加载文件，先向服务端查询哪些分片已经存在，然后只上传缺失的分片。服务端需要提供两个额外的接口：一个是“文件状态检查”，传入文件的唯一标识（通常用文件内容的MD5值），返回“已存在”或“缺失分片列表”；另一个是“完整性确认”，在所有分片上传完后通知服务端去合并。

秒传更简单，就是服务端发现该文件的MD5已经存在，那么根本不需要上传任何分片，直接返回一个成功标志。要计算文件的MD5，前端可以用 crypto.subtle.digest()，但它对大文件计算速度慢，建议在页面空闲时异步计算。如果你不想让前端算MD5，也可以在服务端用PHP计算每个分片的MD5，再结合分片序号生成文件标识，但这样的话断点续传时查询的粒度会更细，实现起来略复杂。

说实话，断点续传和秒传不是必须的，但它们是大文件上传的加分项。如果你只是做一个内部工具，可以把这些功能去掉，只保留切片上传和合并。但如果你做的是对外产品，建议加上，因为用户的网络环境千奇百怪，没有续传机制的上传功能会被骂死。

3. 服务端PHP接收与合并实现

3.1 PHP接收分片并保存临时文件

服务端的第一步比较简单：接收前端POST过来的FormData数据。每个分片附带几个关键字段：分片索引（chunkIndex）、总分片数（totalChunks）、原文件名（fileName），以及文件唯一标识（fileId）。fileId 我一般用前端计算出的文件MD5，或者用 session_id() + 文件名 拼一个标识，但要注意，如果同一个用户上传两个同名文件，后者会覆盖前者。

接收分片时，我会在服务器的临时目录下创建一个以 fileId 命名的子目录，然后将每个分片保存为 chunk_0001.part 这样的文件。索引号要补零，方便后续按字典序排序，虽然我们后面会用数字排序，但补零能让文件名在文件管理器里更直观。保存分片时，PHP用 move_uploaded_file() 函数，将上传的临时文件移动到目标位置。记得检查目标目录是否存在，不存在就递归创建。这里需要特别注意，临时目录不要放在 /tmp 下，因为有些系统会自动清理 /tmp，而且跨分区移动文件时效率不一定高。我通常会在项目目录下建一个 uploads/tmp 目录，并把它排除在Web访问范围之外。

保存分片后，可以返回一个JSON响应，告知前端该分片是否成功。如果某个分片已经存在（之前上传过），可以直接返回成功，这样能省去重复传输。服务端保存分片时还需要考虑并发问题，PHP默认每个请求互不干扰，所以不同分片同时写入不同文件是安全的，只要文件名不冲突就行。

3.2 合并分片的两种方式与参数选择

当所有分片都上传完成后，PHP端需要合并分片。合并有两种常见的方式：

第一种是“顺序拼接法”：用 fopen() 打开最终的目标文件，然后按索引从小到大打开每个分片文件，用 fwrite() 将内容写入目标文件，最后关闭文件并删除分片。这种方式简单直观，占用的内存只相当于一个分片的大小，非常适合大文件。

第二种是“流式合并法”：使用PHP的 stream_copy_to_stream() 函数，将分片文件的数据流直接复制到目标文件流中。这种方式代码更简洁，效率也更高，因为它利用了底层的流复制机制，避免了在一段段循环读取中频繁调用 fwrite。我通常选择第二张方式，性能更好。

在合并前，需要检查是否所有分片都已到位。校验逻辑是：统计目录下的分片文件数量是否等于 totalChunks，同时检查每个分片的大小是否符合预期。分片大小可能不完全一致（最后一个分片一般较小），所以只要检查前 totalChunks-1 个分片的大小等于设定值，最后一个分片大于0就行。如果发现缺失，就返回一个“不完整”状态，让前端补充上传缺失分片。还有一个细节：合并后最好再计算一次合并文件的大小，与前端上传前传过来的文件大小做比对，不一致说明分片有问题，需要重新上传。

合并完成之后，我会把临时分片目录删除掉，避免占用磁盘空间。还要注意，如果用户上传了一部分就取消，服务端需要有一个清理机制，比如临时目录中超过24小时未合并的分片，用定时任务或写一个清理接口手动删除。

3.3 跨平台兼容性处理：路径与文件名

因为PHP可以运行在Windows和Linux上，所以路径分隔符不能写死。PHP提供了 DIRECTORY_SEPARATOR 常量，用 $separator = DIRECTORY_SEPARATOR; 然后拼路径。不过，更推荐的写法是直接用 / 作为路径分隔符，因为PHP在Windows上也能识别 /，而且可读性更好。但我不会在代码里混合使用两种分隔符，统一用 /，这样代码复制到任何服务器上都不会出问题。

文件名编码是另一个坑。浏览器端通过FormData上传的文件名通常以UTF-8编码，但Windows服务器上的文件系统默认使用GBK或本地字符集，如果直接使用 $_FILES['file']['name'] 去创建文件，中文文件名会乱码。解决办法是：服务端不直接使用原始文件名保存，而是生成一个随机文件名（比如 uniqid() 加原始扩展名），或者先对文件名做处理。我会在保存到服务器时使用 rawurldecode() 结合 mb_convert_encoding() 来转换编码，同时用 basename() 过滤掉路径信息，防止目录穿越攻击。

在合并后的最终文件命名上，我建议使用前端传来的原始文件名，但要做安全校验。这里有一个简单的规则：不要直接信任上传文件名，先用 basename() 去掉所有路径，再用正则过滤掉非法字符，比如 /、\0、.. 等。如果文件名过长，可以截断到200个字符以内。这样处理以后，无论在哪个平台，文件都能正常保存和访问。

4. 完整示例：从HTML到PHP的一站式代码

4.1 前端HTML与JavaScript实现（含并发控制）

先分享一段可以实际运行的前端核心代码。这个示例我用了原生JavaScript，不依赖框架，你直接复制到HTML文件里就能用。

html复制<input type="file" id="fileInput" />
<button id="uploadBtn">开始上传</button>
<div id="progress">0%</div>

<script>
const fileInput = document.getElementById('fileInput');
const uploadBtn = document.getElementById('uploadBtn');
const progressDiv = document.getElementById('progress');

const CHUNK_SIZE = 5 * 1024 * 1024; // 5MB
const CONCURRENCY = 3; // 并发数
const MAX_RETRY = 3;

function getFileId(file) {
  // 简化版，生产环境建议用MD5或服务端生成的唯一ID
  return file.name + '_' + file.size + '_' + file.lastModified;
}

function uploadChunk(file, start, end, index, totalChunks, fileId) {
  const chunk = file.slice(start, end);
  const formData = new FormData();
  formData.append('file', chunk, file.name);
  formData.append('chunkIndex', index);
  formData.append('totalChunks', totalChunks);
  formData.append('fileId', fileId);

  return new Promise((resolve, reject) => {
    const xhr = new XMLHttpRequest();
    xhr.open('POST', '/upload.php', true);
    xhr.timeout = 60000;
    xhr.onload = () => {
      if (xhr.status === 200) {
        const resp = JSON.parse(xhr.responseText);
        if (resp.code === 0) resolve(resp);
        else reject(new Error(resp.msg));
      } else {
        reject(new Error('HTTP ' + xhr.status));
      }
    };
    xhr.onerror = () => reject(new Error('网络错误'));
    xhr.ontimeout = () => reject(new Error('超时'));
    xhr.send(formData);
  });
}

uploadBtn.addEventListener('click', async () => {
  const file = fileInput.files[0];
  if (!file) return;

  const totalChunks = Math.ceil(file.size / CHUNK_SIZE);
  const fileId = getFileId(file);
  let uploaded = 0;
  let failedCount = 0;

  // 先检查服务端已有分片（断点续传）
  const checkResp = await fetch('/check.php?fileId=' + encodeURIComponent(fileId));
  const existedChunks = await checkResp.json();
  // 这里返回一个数组，比如 [0, 1, 2]

  const tasks = [];
  for (let i = 0; i < totalChunks; i++) {
    if (existedChunks.includes(i)) {
      uploaded++;
      continue;
    }
    const start = i * CHUNK_SIZE;
    const end = Math.min(file.size, start + CHUNK_SIZE);
    tasks.push({ start, end, index: i });
  }

  const total = tasks.length;
  let nextIndex = 0;

  async function worker() {
    while (nextIndex < total) {
      const task = tasks[nextIndex++];
      let retry = 0;
      let success = false;
      while (retry <= MAX_RETRY) {
        try {
          await uploadChunk(
            file,
            task.start,
            task.end,
            task.index,
            totalChunks,
            fileId
          );
          success = true;
          break;
        } catch (e) {
          retry++;
          console.warn('分片' + task.index + '失败，重试' + retry);
        }
      }
      if (!success) {
        failedCount++;
        console.error('分片' + task.index + '上传失败');
      } else {
        uploaded++;
        progressDiv.textContent =
          Math.round((uploaded / totalChunks) * 100) + '%';
      }
    }
  }

  const workers = [];
  for (let i = 0; i < Math.min(CONCURRENCY, total); i++) {
    workers.push(worker());
  }
  await Promise.all(workers);

  if (failedCount > 0) {
    alert('有 ' + failedCount + ' 个分片失败，请重试');
    return;
  }

  // 通知服务端合并
  const mergeResp = await fetch('/merge.php', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ fileId, fileName: file.name })
  });
  const mergeResult = await mergeResp.json();
  if (mergeResult.code === 0) {
    progressDiv.textContent = '上传成功';
  } else {
    alert('合并失败：' + mergeResult.msg);
  }
});
</script>

注意，check.php、upload.php、merge.php 这三个接口需要后端配合。check.php 返回一个数组，里面是已存在的分片索引。前端会在启动并发队列前调用一次。这段代码我实测在Chrome、Firefox、Edge上都没问题，Safari也支持 file.slice() 和 FormData，可以放心用。

4.2 后端PHP核心处理代码（upload/check/merge）

后端我按三个文件来写，方便你理解各自职责。第一个是 upload.php，处理分片上传；第二个是 check.php，检查已上传分片；第三个是 merge.php，合并分片。

php复制<?php
// upload.php
// 允许跨域（如果前端不在同域）
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: POST');
header('Content-Type: application/json');

$uploadRoot = __DIR__ . '/uploads/tmp/';

if (!is_dir($uploadRoot)) {
    mkdir($uploadRoot, 0777, true);
}

$fileId = $_POST['fileId'] ?? '';
$chunkIndex = $_POST['chunkIndex'] ?? '';
$totalChunks = $_POST['totalChunks'] ?? '';
$fileName = $_POST['fileName'] ?? '';

if ($fileId === '' || $chunkIndex === '' || $totalChunks === '') {
    echo json_encode(['code' => 1, 'msg' => '参数缺失']);
    exit;
}

// 用fileId作为子目录名，防止不同文件混在一起
$targetDir = $uploadRoot . preg_replace('/[^A-Za-z0-9_\-]/', '', $fileId);
if (!is_dir($targetDir)) {
    mkdir($targetDir, 0777, true);
}

// 分片文件名，索引号补零到6位
$chunkName = sprintf('%06d.part', intval($chunkIndex));
$targetFile = $targetDir . '/' . $chunkName;

// 如果分片已存在，直接返回成功（支持断点续传）
if (file_exists($targetFile)) {
    echo json_encode(['code' => 0, 'msg' => '分片已存在']);
    exit;
}

if (!isset($_FILES['file']) || $_FILES['file']['error'] !== UPLOAD_ERR_OK) {
    echo json_encode(['code' => 1, 'msg' => '上传错误']);
    exit;
}

// 移动上传临时文件到目标分片文件
if (move_uploaded_file($_FILES['file']['tmp_name'], $targetFile)) {
    echo json_encode(['code' => 0, 'msg' => '分片上传成功']);
} else {
    echo json_encode(['code' => 1, 'msg' => '分片保存失败']);
}

php复制<?php
// check.php
header('Content-Type: application/json');

$uploadRoot = __DIR__ . '/uploads/tmp/';
$fileId = $_GET['fileId'] ?? '';
if ($fileId === '') {
    echo json_encode([]);
    exit;
}

$targetDir = $uploadRoot . preg_replace('/[^A-Za-z0-9_\-]/', '', $fileId);
$existed = [];
if (is_dir($targetDir)) {
    $files = scandir($targetDir);
    foreach ($files as $f) {
        if (preg_match('/^(\d{6})\.part$/', $f, $m)) {
            $existed[] = intval($m[1]);
        }
    }
}
echo json_encode($existed);

php复制<?php
// merge.php
header('Content-Type: application/json');

$json = file_get_contents('php://input');
$data = json_decode($json, true);
$fileId = $data['fileId'] ?? '';
$fileName = $data['fileName'] ?? '';

if ($fileId === '' || $fileName === '') {
    echo json_encode(['code' => 1, 'msg' => '参数缺失']);
    exit;
}

$uploadRoot = __DIR__ . '/uploads/tmp/';
$fileIdSafe = preg_replace('/[^A-Za-z0-9_\-]/', '', $fileId);
$targetDir = $uploadRoot . $fileIdSafe;

if (!is_dir($targetDir)) {
    echo json_encode(['code' => 1, 'msg' => '分片不存在']);
    exit;
}

// 获取所有分片并按索引排序
$chunkFiles = glob($targetDir . '/*.part');
if (count($chunkFiles) == 0) {
    echo json_encode(['code' => 1, 'msg' => '没有分片']);
    exit;
}

// 按索引排序
usort($chunkFiles, function($a, $b) {
    $indexA = intval(pathinfo($a, PATHINFO_FILENAME));
    $indexB = intval(pathinfo($b, PATHINFO_FILENAME));
    return $indexA - $indexB;
});

// 最终保存目录
$saveRoot = __DIR__ . '/uploads/final/';
if (!is_dir($saveRoot)) {
    mkdir($saveRoot, 0777, true);
}

// 清理文件名，防止路径穿越和非法字符
$fileName = basename($fileName);
$fileName = preg_replace('/[\\/:*?"<>|]/', '_', $fileName);
if (mb_strlen($fileName) > 200) {
    $fileName = mb_substr($fileName, 0, 200);
}

$finalPath = $saveRoot . $fileName;

// 合并分片
$outFile = fopen($finalPath, 'wb');
if (!$outFile) {
    echo json_encode(['code' => 1, 'msg' => '无法创建最终文件']);
    exit;
}

foreach ($chunkFiles as $chunkFile) {
    $inStream = fopen($chunkFile, 'rb');
    stream_copy_to_stream($inStream, $outFile);
    fclose($inStream);
}

fclose($outFile);

// 合并完成后删除临时目录
array_map('unlink', $chunkFiles);
rmdir($targetDir);

echo json_encode([
    'code' => 0,
    'msg' => '上传成功',
    'url' => '/uploads/final/' . rawurlencode($fileName)
]);

这三个文件构成了后端的基本流程。这里我特意用 preg_replace('/[^A-Za-z0-9_\-]/', '', $fileId) 来过滤 fileId，防止用户传一个包含目录穿越的 fileId 去读写任意路径。这是一个安全底线，不建议省略。

4.3 配置调整：Nginx与Apache的上传大小和超时

代码写好了，如果服务器的web层限制还卡着，照样传不上去。这里分两种情况。

如果你用的是Nginx，需要在 nginx.conf 的 server 块或 location 块中调整两个参数：client_max_body_size 和 client_body_timeout。client_max_body_size 设置请求体最大值，既然我们是分片上传，这个值只需要大于最大分片大小即可，比如设置成 20m。同时 client_body_timeout 建议设为60秒，避免上传分片时因为网络慢而断开。

如果你用的是Apache，对应需要调整 php.ini 里的几个参数，同时也要注意Apache的 LimitRequestBody 指令（默认不限制）。PHP这边核心参数有四个：upload_max_filesize、post_max_size、max_execution_time、max_input_time。由于分片上传每个分片只有几MB，所以 upload_max_filesize 设为20MB绰绰有余；但 post_max_size 要同时设为20MB以上，因为它要覆盖整个POST体。max_execution_time 建议设为300秒，脚本合并大文件时耗时较长。max_input_time 用来限制接收请求体数据的时间，也要调到300。

修改完配置后，记得重启Nginx或Apache，然后用 phpinfo() 或命令行 php -i | grep upload_max 确认配置已生效。这里有一个容易踩的坑：在Nginx + PHP-FPM环境下，不仅要改Nginx的 client_max_body_size，还要同时改PHP的 upload_max_filesize 和 post_max_size，两边是串联关系，任何一边没改都会失败。

5. 常见问题与排查技巧实录

5.1 上传大文件老是超时或报502

这个问题我遇到过很多次，尤其在Nginx + PHP-FPM的组合下。502通常意味着PHP-FPM进程崩溃或超时退出，最常见的原因是 request_terminate_timeout 设置得太短，比如默认的30秒。如果你合并一个大文件耗时较长，超过这个值就会被kill。解决办法是在 php-fpm.d/www.conf 中调大 request_terminate_timeout，我一般设为300秒。

另一个排查点是设备存储空间。如果 uploads/tmp 所在磁盘满了，分片写入会失败，然后前端反复重试，最终表现为上传进度卡住或服务端报错。我的建议是在监控中加入磁盘使用率告警，同时定期清理临时分片。清理策略可以写一个crontab脚本，删除创建时间超过24小时的 .part 文件和临时目录，避免磁盘被垃圾占满。

如果你用的是Apache，还有一种情况是 mod_fcgid 的 FcgidIOTimeout 或 IPCCommTimeout 设置过短，导致上传过程中连接被断开。可以适当调大，比如设为300秒。总的来说，超时问题要先分清是哪一层超时：浏览器层、Nginx层、PHP层还是PHP-FPM层，然后对症下药。

5.2 分片顺序错乱导致文件损坏

合并后的文件损坏，通常是分片顺序错乱了。我在代码里用 usort() 按索引排序，这是安全的做法。但你可能会遇到一种情况：前端切片的索引是从0开始的，后端排序时却用了字符串排序，结果是 0.part, 10.part, 11.part 排在了 2.part 前面，导致合并顺序错误。所以，在合并之前，务必把索引解析成整数再排序，不能直接按文件名排序。

还有一个容易被忽略的情况：同一个文件被重复上传，但 fileId 相同，前端和后端的索引都对应上了，可磁盘上旧分片没有清理干净。例如用户上次上传中断，残留了第0、1、2个分片；这次重新上传，前端的 check.php 返回了已存在的分片索引，于是第0、1、2个分片就跳过了。但是，如果上次上传的分片大小和这次配置的分片大小不一致，那么合并后文件就可能损坏。解决方法是：在 check.php 返回已存在分片时，同时也把每个分片的大小返回给前端，前端比对当前切片大小，不一致则视为无效分片。

合并完成后，我还建议做一个完整性校验：前端在文件上传前计算好文件MD5，合并后PHP端计算合并文件的MD5，做比对。如果一致再返回成功，不一致则说明分片有误，可以让用户重新上传。这个能力对产品品质来说很重要，但会增加一定的计算开销，我一般会做成可配置项，默认开启。

5.3 跨平台中文文件名乱码与下载问题

中文文件名的问题不只在保存时容易出现，在下载时也会麻烦。如果你把文件名保存成UTF-8编码的中文文件到Linux服务器，浏览器访问该文件时，如果HTTP响应头没有设置正确的 Content-Disposition，文件名可能显示乱码。这时需要后端在返回下载响应时对文件名做URL编码：

php复制header('Content-Disposition: attachment; filename="' . rawurlencode($fileName) . '"');

同时，在保存文件时，如果你想在Windows服务器上确保文件名正常，可以用 mb_convert_encoding($fileName, 'GBK', 'UTF-8') 再作为文件系统文件名。但是，如果你在Linux服务器上用GBK保存，反而可能出问题。我的建议是服务器端统一使用UTF-8保存文件，只在前端显示和下载时处理编码兼容。

另外一个细节是：很多用户在文件名字里带了空格、#、% 等字符，如果你直接拼接URL链接，这些字符需要做URL编码。用 rawurlencode() 处理最稳妥。我用的是 '/uploads/final/' . rawurlencode($fileName)，这样生成的URL在浏览器里可以直接访问。

5.4 并发分片导致服务器内存或连接数爆掉

分片并发虽然能提升上传速度，但如果并发数设置过高，比如把10个并发全开，每上传一个分片PHP-FPM就会占用一个进程，如果同时有很多用户上传，服务器可能直接被连接数打爆。我这里建议三个措施：一是限制前端的并发数，控制在3-5个；二是在Nginx层设置 limit_conn 或 req_zone 限制单IP上传速率；三是在PHP侧设置 upload_progress 功能，清理掉过期的上传会话。注意，即使并发数不高，如果服务器配置比较低，内存也可能成为瓶颈，因为PHP-FPM的 pm.max_children 决定同时能处理多少请求，如果所有子进程都在写分片，内存自然会上升。

在这里分享一个我实际用过的优化：将分片临时目录放到内存文件系统，比如 /dev/shm。因为分片文件的写入和读取非常频繁，内存文件系统性能远高于普通磁盘。但要注意，重启后数据会丢失，所以只适合存储临时分片。对于最终合并后的文件，仍然保存到磁盘或对象存储里。不过这个方案依赖服务器的操作系统，如果你用的是虚拟主机，可能没有权限，落地前先确认环境。

使用 stream_copy_to_stream 合并文件时，PHP不会一次将整个文件加载到内存，而是以流的方式复制，所以内存占用较低。但我发现，如果在合并过程中其他PHP请求正好都在处理分片上传，内存峰值依然可能上去。建议在合并接口里加入一个简单的锁，避免同一时间多个合并任务同时执行。可以用 flock 加锁或者利用数据库锁，具体看你项目的技术栈。

写在最后：几个让我少踩坑的习惯

这套分片上传方案我一直在用，也迭代了好几次。最初我只写了两段代码，一个前端切片，一个后端拼接，后来才发现断点续传、安全过滤、并发控制、超时处理这些细节才是真正的工程量。如果你也想把这个方案落地，我建议你从最小可运行版本开始，先不要加断点续传和秒传，只实现切片上传和合并，跑通后再逐步加功能。

最后说两个我手上的小技巧：第一，分片上传接口的返回值一定要有明确的错误码和错误消息，方便前端定位问题，不要只返回 200 或 500，而是返回 {code: 0|1, msg: '...'} 这种结构化数据，后续排查效率高很多。第二，临时文件名都用 %06d 补零，我发现很多同事在这个细节上翻车，导致合并时排序错乱，虽然 usort 能兜底，但补零之后的文件名也更方便你在终端里手动查看分片状态。

后续如果你想在这个方案上继续扩展，可以考虑把分片元数据放到Redis里，合并前先检查所有分片是否就绪，再触发后台队列去合并，这样用户体验可以做得更顺滑。但那是另一个复杂度了，先把当前的代码吃透，再一步步优化，才是稳妥的路子。