PHP接收POST参数超限的根本原因是post_max_size或upload_max filesize设置过小，需同步调整Nginx/Apache及PHP配置并验证全链路生效。
PHP 接收 POST 参数长度超限，根本原因通常是 post_max_size 或 upload_max_filesize 设置过小，而非参数个数或键名长度问题。直接调大这两个值就能解决绝大多数“收不到完整表单”“$_POST 为空”“file_get_contents('php://input') 截断”等现象。
确认是不是 post_max_size 触发了截断
PHP 在请求体超过 post_max_size 时，会静默丢弃整个 POST 数据（包括 $_POST、$_FILES 和 php://input），且不报错——这是最易被忽略的关键点。
- 检查错误日志：启用
log_errors = On并查看 PHP 错误日志，若出现PHP Warning: POST Content-Length of XXX bytes exceeds the limit of YYY bytes，就是它 - 临时验证：在脚本开头加
var_dump($_POST, $_FILES, strlen(file_get_contents('php://input')));，若全为空但Content-Length头很大，基本可锁定 -
post_max_size默认通常为8M，而upload_max_filesize默认常为2M，后者必须 ≤ 前者，否则上传会失败
修改 post_max_size 的三种生效方式
必须确保修改位置与 PHP 运行模式匹配，否则无效。常见误区是改了 php.ini 却用的是 CGI/FPM 模式下的独立配置。
- 全局修改（推荐）：编辑实际生效的
php.ini文件（用php --ini或phpinfo()查路径），修改两行：post_max_size = 64M upload_max_filesize = 64M
注意：upload_max_filesize必须 ≤post_max_size - FPM 场景：若用 PHP-FPM，优先在对应 pool 的
.conf中设：php_admin_value[post_max_size] = 64M php_admin_value[upload_max_filesize] = 64M
这样比改全局php.ini更安全 - 运行时不可靠：
ini_set('post_max_size', '64M')无效——该指令为PHP_INI_PERDIR级别，只能在配置文件中设置
还要同步检查的关联限制
光调 post_max_size 不够，Nginx、Apache、甚至前端 JS 的发送逻辑都可能拦在半路。
立即学习“PHP免费学习笔记（深入）”；
- Nginx：必须设
client_max_body_size 64M;（在http、server或location块中），否则请求根本进不了 PHP - Apache：检查
LimitRequestBody（默认无限制，但若显式设了小值需调大） - 超时相关：大 POST 容易触发
max_execution_time或max_input_time，建议一并检查；例如max_input_time = 300（单位秒） - 前端注意：用
fetch或XMLHttpRequest发送大量数据时，确保没手动截断或分块逻辑出错
真正麻烦的不是改哪个值，而是要同时确认 Web 服务器层、PHP 配置层、运行时环境三者是否一致生效——漏掉任意一层，都会让你以为“明明改了却没用”。尤其上线前务必用真实大 payload 测试整条链路。
