如何在不修改php.ini的情况下导入大文件_分割工具与逐个上传-phpMyAdmin-PHP中文网

不能改 php.ini 时，必须采用前端分片上传+后端按序合并方案：前端切片（如每2MB）、后端用 fopen('c') + fseek 定位写入临时分片，全部接收后再校验哈希并设权限。

upload_max_filesize 超了但改不了 php.ini 怎么办

直接说结论：不能改 php.ini 时，靠前端分片 + 后端合并是最可行的路径。php 的 upload_max_filesize 和 post_max_size 是硬限制，运行时无法用 ini_set() 绕过，任何试图“临时调大”的操作都无效。

常见错误现象是表单提交后直接 400 或空白页，查 error_log 会看到类似 PHP Warning: POST Content-Length of XXX bytes exceeds the limit of YYY bytes 的报错 —— 这说明请求根本没进脚本，更别提执行逻辑了。

必须在前端把文件切片（例如每 2MB 一片），用 fetch 或 XMLHttpRequest 分批上传
后端接收时不做完整校验，只存临时分片（命名带序号和唯一标识，如 upload_abc123_001.tmp）
所有分片上传完成后，再用 file_put_contents() 配合 FILE_APPEND 合并，**不要用 file_get_contents() 全读进内存**
合并完立刻校验 md5_file() 或 sha1_file()，比对前端传来的总哈希值

用 curl 或命令行模拟分片上传调试

浏览器上传容易卡在 CORS、超时或 chunk 失序，本地用 curl 直接发请求能快速验证后端接口是否健壮。关键不是“能不能传”，而是“断点续传”和“重复片去重”有没有做。

使用场景包括：测试大文件中断后重试、检查分片序号错位是否导致合并乱序、确认临时目录权限是否允许写入大量小文件。

上传第 1 片：curl -F "chunk=0" -F "total=5" -F "identifier=xyz" -F "file=@part1.bin" https://yoursite.com/upload.php
上传第 3 片（跳过第 2 片）：curl -F "chunk=2" -F "total=5" -F "identifier=xyz" -F "file=@part3.bin" https://yoursite.com/upload.php
后端必须支持“任意顺序接收”，靠 identifier 和 chunk 索引分片，不能依赖请求先后
临时分片建议存到 /tmp/uploads/ 这类可写路径，避免和 Web 根目录混在一起

合并时 `fopen()` 模式选错导致文件损坏

合并大文件最常踩的坑是用了 fwrite(fopen($target, 'w'), $content) —— 'w' 模式每次打开就清空文件，最后只剩最后一片内容。正确做法是只开一次句柄，用 FILE_APPEND 或 fseek() 定位写入。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

性能影响很明显：1GB 文件如果每片都 fopen(..., 'w') 再 fclose()，IO 开销翻倍；而用 fopen(..., 'c') + fseek() 定位写入，能省掉大量磁盘寻道时间。

推荐方式：$fp = fopen($target, 'c'); fseek($fp, $offset); fwrite($fp, $chunk_data); fclose($fp);
不推荐方式：file_put_contents($target, $chunk_data, FILE_APPEND) —— 它内部每次都会重新 open/close，高并发下容易锁冲突
务必检查 fopen() 返回值，false 说明磁盘满或权限不足，别直接 fwrite() 导致 PHP Warning
合并完成后用 chmod($target, 0644) 显式设权限，避免继承临时目录的 0600

Chrome 上传大文件卡在 pending 的真实原因

不是网络慢，大概率是服务端没及时响应分片请求，触发了浏览器的默认 timeout（通常 5 分钟）。哪怕后端 PHP 脚本还在跑，只要没输出 HTTP 头，Chrome 就算“卡住”。

兼容性影响在于：Safari 对单个请求 timeout 更激进（约 90 秒），而 Node.js 后端默认无此限制，所以换后端语言并不能绕开这个问题 —— 根子在 HTTP 协议层的客户端行为。

每个分片上传接口必须在 30 秒内返回 HTTP/1.1 200 OK，哪怕只是 {"status":"received","chunk":2}
禁用 set_time_limit(0) 来“保命”，它只防脚本超时，不防 Apache/Nginx 的 Timeout 或 proxy_read_timeout
Nginx 用户重点检查 client_max_body_size 和 fastcgi_read_timeout，这两个值比 PHP 的 upload_max_filesize 更早拦截请求
上传进度条别只信 XMLHttpRequest.upload.onprogress，它不反映服务端处理状态，得靠轮询合并接口的 status 字段