修改 post_max_size 无效需先确认 php.ini 加载路径，区分 cli/web 配置；必须同步调整 upload_max_filesize、memory_limit、web 服务器限制（如 nginx client_max_body_size）及超时参数。
php8.5 修改 post_max_size 有效但不生效？先看 ini 文件加载顺序
改了 php.ini 里的 post_max_size，phpinfo() 却没变——大概率是改错了文件。PHP 8.5 启动时会按固定顺序加载多个配置文件，优先级高的会覆盖低的。php --ini 能看到实际加载路径，而 phpinfo() 页面顶部的 “Loaded Configuration File” 才是你该改的那个文件。
- CLI 和 Web（如 Apache/Nginx）可能用不同
php.ini：CLI 看php --ini，Web 看phpinfo()输出 - 某些 Docker 镜像或云环境会通过
.htaccess、user.ini或php_admin_value强制覆盖，这些不能被运行时函数修改 - 值必须带单位，
post_max_size = 64M合法，post_max_size = 64默认是字节，等于限制 64 字节 —— 这是常见误配
php8.5 中 post_max_size 和 upload_max_filesize 必须同时调大
post_max_size 是整个 POST 请求体上限（含表单字段 + 文件），而 upload_max_filesize 只管单个上传文件。如果只调大前者，上传大文件仍会失败，错误日志里常出现 PHP Warning: POST Content-Length of XXX bytes exceeds the limit 或静默截断。
- 设
upload_max_filesize = 32M，则post_max_size至少设为33M（留出其他字段空间） - 若用
curl或 API 工具发 JSON 表单，也受post_max_size限制，不是只有<form enctype="multipart/form-data"></form>才走这条链路 - PHP 8.5 不再容忍
post_max_size ，启动时会报 <code>Warning: Invalid value for 'post_max_size'
修改后重启服务不彻底？确认 SAPI 类型再操作
PHP 8.5 的配置变更是否生效，取决于你用的是哪种 SAPI（Server API）。改完 php.ini 后：
- Apache：必须重启
httpd或apache2进程，仅 reload 不够（模块已加载，ini 在进程启动时读取） - Nginx + PHP-FPM：要
systemctl restart php-fpm，不是只 reload nginx；FPM worker 进程不重启，新配置不会加载 - CLI 或测试脚本：直接生效，无需重启，但注意 CLI 用的是独立配置
- Docker 容器：改宿主机挂载的 ini 文件后，必须
docker restart，build 镜像时写死的配置不会自动更新
为什么调到 2G 还报错？内存和超时也得同步调
post_max_size 不是唯一瓶颈。PHP 8.5 解析大 POST 数据时，会把整个请求体读进内存，若 memory_limit 不够，会触发 Fatal error: Allowed memory size exhausted；若请求时间太长，max_execution_time 或 Web 服务器超时（如 Nginx 的 client_max_body_size、fastcgi_read_timeout）也会中断连接。
立即学习“PHP免费学习笔记（深入）”；
- Web 服务器层必须同步放开限制：Nginx 要加
client_max_body_size 2G到http、server或location块 -
memory_limit建议 ≥post_max_size，否则解析阶段就崩了 - 上传大文件时，
max_input_time也要延长，否则在数据接收中途就被终止
post_max_size 看似一行配置，实际牵扯 PHP 加载机制、SAPI 行为、Web 服务器协同和内存模型。最容易漏的是 Nginx 的 client_max_body_size —— 它根本不会进 PHP，请求在网关层就被拒了。 
