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 错误。这是最常被忽略的一环。
Automated daily memory backfill for OpenClaw sessions
下载
抓取并分析 OpenClaw JSONL 会话日志，重建并回填代理记忆文件。适用于：(1) 模型切换后记忆不完整，(2) 验证记忆覆盖度，(3) 重建丢失记忆，(4) 通过 cron/heartbeat 自动同步每日记忆。支持简单提取及基于 LLM 的叙事摘要，并自动清理敏感信息。
- 在
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——无状态部署下不可靠
