PHP文件上传大小限制需同时修改php.ini中的upload_max_filesize和post_max_size，并同步调整Nginx的client_max_body_size；断点续传需前端分片+服务端状态持久化实现。
PHP 文件上传默认限制在哪改
PHP 默认限制上传文件大小为 2MB，主要受两个配置项控制：upload_max_filesize 和 post_max_size。前者限制单个文件，后者限制整个 POST 请求体（含多个文件 + 表单字段）。必须同时调大，且 post_max_size ≥ upload_max_filesize。
-
upload_max_filesize = 100M（写在php.ini或.user.ini） -
post_max_size = 128M（不能只改一个） - 改完记得重启 PHP-FPM 或 Web 服务器（Apache/Nginx 不会自动重载 PHP 配置）
- 用
phpinfo()或ini_get('upload_max_filesize')确认生效，别只改了配置文件却没生效
大文件上传中断后怎么续传（客户端+服务端配合）
HTTP 协议本身不支持断点续传，必须靠前端分片 + 后端校验拼接实现。核心不是“PHP 能不能续”，而是“你有没有设计分片上传逻辑”。
- 前端用
File.slice()（浏览器 API）把文件切块（如每块 5MB），按顺序发带序号的请求 - 服务端接收时记录每个块的
filename、chunk_index、total_chunks、md5（可选） - 存临时目录（如
/tmp/uploads/{file_id}/part_001），不要直接写入最终路径 - 所有块收齐后，用
file_put_contents($final, file_get_contents($part), FILE_APPEND)拼接，或用cat命令（Linux）更高效 - 关键：上传前先发个 HEAD 请求查服务端是否已有该文件的完成标记或部分块，决定从哪片开始传
为什么 Nginx 会 413 Request Entity Too Large
即使 PHP 配置调大了，Nginx 默认只允许 1MB 的请求体，它会在请求到达 PHP 前就拦截并返回 413 错误。这是最常被忽略的一环。
- 在
nginx.conf或站点配置里加：client_max_body_size 200M（放在http、server或location块中） - 如果用的是反向代理（如 Nginx → PHP-FPM），还要确认
fastcgi_buffers和fastcgi_buffer_size足够大，否则大 POST 可能触发 502 - 修改后必须
nginx -t && nginx -s reload，仅重启 PHP 进程无效 - 错误日志里搜
"client intended to send too large body"就是它
上传中途失败，用户刷新页面后怎么避免重复上传
不能靠前端 JS 记录状态（刷新即丢），得靠服务端生成唯一上传 ID 并持久化。
立即学习“PHP免费学习笔记（深入）”；
- 用户第一次访问上传页时，后端生成 UUID 作为
upload_id，存进 Redis 或数据库，初始状态为pending - 每个分片请求都带上这个
upload_id，服务端用它查当前已收到哪些块 - 前端上传前先 GET
/api/upload/status?upload_id=xxx，拿到已传块列表，跳过重传 - 最终合并成功后，把状态改成
completed，并清理临时文件；超时未完成（如 24h）则自动清理 - 别用文件名做 key——同名文件多次上传会冲突；也别用 session_id——无状态部署下不可靠
