PHP文件上传：大文件切片上传与进度反馈

设计大文件切片上传流程

大文件直接上传极易受限于服务器配置（如upload_max_filesize）与网络波动，导致传输中断或内存溢出。切片上传的核心思路是将完整文件在前端按固定大小（如5MB）切割为多个二进制块。通过JavaScript的File.slice(start, end)方法可精准截取数据，并为每个分片分配递增序号（如chunkIndex）与基于文件内容哈希（如MD5或SparkMD5）生成的唯一标识fileHash。前端使用FormData对象封装分片数据，附加fileHash、chunkIndex、totalChunks等元信息，通过AJAX或Fetch逐片提交至PHP接口。整体流程中，服务端需维护分片状态记录（如Redis或数据库表），记录已接收的分片序号。断点续传依赖这些状态数据：当网络恢复或页面刷新后，前端先请求服务端已上传的分片列表，跳过已存在的分片继续上传剩余部分，从而避免重复传输与资源浪费。

PHP接收分片与安全校验

PHP接收分片时，首先通过$_FILES获取临时文件，并读取前端传递的fileHash与chunkIndex。服务端需动态创建临时存储目录，路径建议采用/tmp/uploads/{fileHash}/结构，确保不同文件的分片隔离。分片保存时，使用move_uploaded_file()将临时文件重命名为{chunkIndex}.part。安全校验是重中之重：必须严格校验$_FILES['file']['size']是否超出预设阈值，通过finfo_open(FILEINFO_MIME_TYPE)验证真实MIME类型而非依赖前端后缀，并过滤危险扩展名（如.php、.exe）。分片序号需校验范围合法性，防止越界写入。为防范路径穿越攻击，应对fileHash进行白名单过滤或强制转义，禁止包含../等字符。同时，设置目录权限为0750，避免其他用户读取。若发现同名分片已存在，应直接跳过或返回成功状态，防止恶意覆盖导致数据损坏。

合并分片并验证完整文件

当所有分片上传完毕，前端触发合并请求。PHP端首先扫描临时目录，按序号排序检查分片完整性。若发现缺失分片，应返回错误码要求前端补传；若存在重复分片，可安全覆盖或忽略。合并操作推荐使用fopen以二进制追加模式（ab）循环读取各.part文件并写入目标文件，避免一次性加载全部数据到内存。合并完成后，必须计算最终文件的MD5或SHA256哈希值，与前端初始计算的fileHash进行比对，确保数据未损坏。临时分片目录应在合并成功后立即通过递归删除清理，释放磁盘空间。针对高并发场景，合并接口需加分布式锁（如Redis SETNX），防止多进程同时合并导致文件损坏。若合并中途失败，应保留已写入的部分并记录日志，提供重试机制或回滚策略，确保最终文件一致性。

实现上传进度反馈与断点续传

上传进度反馈依赖前端对已传输数据的精确统计。通过监听XMLHttpRequest.upload.onprogress事件，可获取loaded与total字节数，结合已上传分片数量计算百分比进度。为提升效率，可采用并发上传策略（如同时发起3-5个分片请求），但需控制最大并发数以防浏览器连接池耗尽。服务端提供独立的状态查询接口，前端定时轮询或基于WebSocket获取已接收分片列表，实现断点续传。当网络中断或请求失败时，前端捕获错误并启动指数退避重试机制，仅重传失败分片。页面刷新后，利用localStorage或sessionStorage缓存fileHash与已传分片索引，重新初始化上传任务时先向服务端查询进度，无缝衔接断点。进度UI需实时展示上传速度、剩余时间及分片状态（成功/失败/重试），确保用户体验流畅。

测试验证与常见避坑

验证阶段需覆盖从几KB到数GB的测试用例。使用curl或Postman模拟分片上传，检查服务端分片落盘与合并逻辑；通过篡改分片序号或注入非法文件验证安全拦截。最终文件务必使用md5sum或sha256sum比对哈希，确认完整性。模拟弱网环境（如Chrome DevTools限速）测试断点续传与重试机制，验证并发上传下的锁竞争与数据一致性。常见避坑包括：PHP默认post_max_size与upload_max_filesize限制需同步调大；max_execution_time与max_input_time需延长以防超时中断；合并大文件时避免使用file_get_contents导致内存溢出，应坚持流式读写；磁盘空间不足时需提前监控并清理临时目录；安全层面严禁信任前端MIME，必须服务端二次校验。通过系统化压测与日志追踪，可构建稳定可靠的大文件上传服务。