分片上传+后端合并是处理大文件的正确方案，因单纯调大upload_max_filesize会受Nginx client_max_body_size、PHP超时与内存限制制约，且无法实现断点续传、校验和并发控制；前端须用Blob.slice()手动分片而非原生表单提交。
PHP 默认无法直接处理超过 upload_max_filesize 或 post_max_size 限制的大文件，硬调高配置不仅不安全，还容易触发超时、内存溢出或被 Nginx/Apache 拦截。真正可行的方案是「分片上传 + 后端合并」，而非单纯改 php.ini。
为什么不能只调大 upload_max_filesize
即使把 upload_max_filesize 和 post_max_size 都设为 2G，实际仍会卡在：
– Web 服务器（如 Nginx）默认 client_max_body_size 是 1M；
– PHP 的 max_execution_time 和 memory_limit 会让大文件读取中途失败；
– 单次上传失败需重传全部，用户体验差；
– 无法校验中间片、断点续传、并发上传控制。
前端必须用 Blob.slice() 分片，不能靠表单 submit
原生 <input type="file"> 提交是整包发送，无法控制分片逻辑。必须用 JavaScript 读取 File 对象后手动切片：
const file = input.files[0];
const chunkSize = 5 * 1024 * 1024; // 5MB
for (let start = 0; start < file.size; start += chunkSize) {
const blob = file.slice(start, Math.min(start + chunkSize, file.size));
// 发起 multipart/form-data 请求，附带 chunk_index、total_chunks、file_id
}关键点：
– 每个请求带唯一 file_id（如 UUID），服务端靠它聚合同一文件的分片；
– 必须传 chunk_index 和 total_chunks，否则无法正确拼接；
– 建议加 MD5（前端计算）校验单片完整性，避免网络损坏。
立即学习“PHP免费学习笔记（深入）”；
PHP 后端接收分片并安全合并
接收端不做完整文件写入，而是存为临时分片（带 hash 或序号后缀），合并前校验所有片是否存在且大小匹配：
- 分片保存路径建议：
/tmp/uploads/{file_id}/chunk_{index}.bin，避免命名冲突 - 用
move_uploaded_file()接收，别用file_get_contents($_FILES['file']['tmp_name'])，防止内存爆掉 - 合并时用
fopen(..., 'wb')+fwrite()逐片追加，不要一次性file_put_contents($final, implode('', $chunks)) - 合并完成后，用
hash_file('sha256', $final)对比前端传来的总 hash，确认完整无篡改 - 务必清理临时分片目录（成功/失败都要），可用
register_shutdown_function()或队列异步清理
Nginx 和 PHP-FPM 的配套调整不可跳过
光改 PHP 配置没用，Nginx 层必须同步放开限制，并禁用缓冲干扰：
location /upload {
client_max_body_size 0; # 关闭大小限制（由业务逻辑控制）
client_body_timeout 300; # 允许长连接上传
proxy_buffering off; # 禁用代理缓冲，避免截断流
fastcgi_read_timeout 300;
}PHP-FPM 中也要调：
– request_terminate_timeout = 300
– php_admin_value[memory_limit] = 256M（不是 2G！够用即可）
– 禁用 output_buffering，防止响应卡住
分片上传的复杂度不在 PHP 代码本身，而在于前后端状态协同：file_id 生命周期管理、重复分片去重、超时分片自动清理、跨机器部署时的共享存储选型（如用 Redis 记录上传进度）。这些细节漏掉一个，就可能产生脏数据或卡死流程。
