如何用PHP实现音频上传的断点续传-php教程-PHP中文网

php不支持真正的http断点续传，仅能实现前端分片上传+服务端合并；需校验identifier、chunk_index，用move_uploaded_file安全接收，合并时优先用ffmpeg修复音频结构。

如何用php实现音频上传的断点续传

PHP本身不直接处理断点续传，关键在客户端分片 + 服务端合并

断点续传不是PHP函数一键开启的功能。它依赖前端把大音频文件切片（如每5MB一片），按顺序上传，服务端只负责接收、校验、暂存、最后合并。PHP的作用是接收$_FILES、验证Content-Range头（如果用标准HTTP Range）、检查MD5/分片序号、写入临时目录，而非“接管TCP连接”或“恢复socket传输”。

常见错误现象：upload_max_filesize限制导致单片上传失败；未校验filename和chunk_index导致覆盖写入；合并时文件句柄未fclose()引发损坏。

必须关闭post_max_size和upload_max_filesize的默认限制（设为0或足够大），否则单片就超限
不要依赖$_SERVER['HTTP_RANGE']做续传判断——浏览器上传分片通常走POST而非GET，真正靠的是前端传来的chunk_index、total_chunks、identifier等字段
每个分片建议保存为{identifier}_{chunk_index}.part，避免不同用户/文件冲突

如何安全接收并校验音频分片

接收端要防御重放、乱序、缺失和恶意覆盖。不能只信前端传的chunk_index，必须结合identifier（如文件名+时间戳+随机串的MD5）做目录隔离，并记录已收分片清单。

示例逻辑片段（非完整脚本）：

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

$identifier = $_POST['identifier'] ?? '';
$chunkIndex = (int)($_POST['chunk_index'] ?? -1);
$totalChunks = (int)($_POST['total_chunks'] ?? 1);

if (!$identifier || $chunkIndex = $totalChunks) {
    http_response_code(400);
    exit('Invalid chunk info');
}

$uploadDir = 'uploads/' . $identifier . '/';
if (!is_dir($uploadDir)) mkdir($uploadDir, 0755, true);

$tmpFile = $uploadDir . $chunkIndex . '.part';
if (move_uploaded_file($_FILES['file']['tmp_name'], $tmpFile)) {
    // 可选：计算该分片MD5，写入uploadDir/.done列表
}

务必用move_uploaded_file()而非copy()，防止文件上传漏洞
音频类型校验不能只看$_FILES['file']['type']（前端可伪造），应调用finfo_open(FILEINFO_MIME_TYPE)读取真实MIME
对$identifier做白名单过滤（如preg_replace('/[^a-zA-Z0-9_\-]/', '', $identifier)），防止路径穿越

合并分片时如何避免音频损坏

合并不是简单cat拼接，音频格式（如MP3、AAC）有帧头、ID3标签、末尾填充等结构。直接按字节追加可能破坏同步字节或元数据，导致播放卡顿或无法识别。

正确做法是：先确认所有分片已收齐（比对.done清单或检查文件数），再用二进制模式逐片fread()+fwrite()，且跳过首片的ID3v2（如果存在）、末片保留ID3v1（如果存在）——但更稳妥的是交由ffmpeg命令行修复：

exec("ffmpeg -f concat -safe 0 -i &1", $output, $returnCode);

纯PHP合并仅适用于无元数据的原始PCM或已知结构简单的格式（如WAV头固定44字节），不推荐用于MP3/AAC/M4A
若必须PHP合并，需用fopen($finalPath, 'wb')打开目标文件，然后对每个分片fopen($part, 'rb')→fread()→fwrite()，全程禁用文本转换（即不用'r'或'w'，用'rb'/'wb'）
合并后务必用getid3库或ffprobe验证时长和码率是否合理，防止静音或截断

为什么你很难在PHP里实现真正的“断点”（而不是“分片续传”）

真·HTTP断点续传（RFC 7233）要求服务端支持206 Partial Content响应，客户端用Range: bytes=1000-2000请求指定区间。但上传场景中，浏览器<input type="file">不发Range头，Fetch API也不允许手动设置Range用于POST上传。所以所谓“断点续传”，99%是前端JS库（如uppy、plupload）实现的分片+重试+索引管理，PHP只是个被动接收者。