php表单post为空而get正常，主因是post_max_size或upload_max_size设得太小；需同步调整二者并重启php-fpm/apache，注意memory_limit、nginx client_max_body_size及cdn/waf限制。
PHP表单提交失败，$_POST 为空但 $_GET 正常
这是典型的 POST 数据被截断或丢弃的表现。Apache 本身不限制 POST 大小，真正起作用的是 PHP 的配置项。用户看到表单“没反应”、后端收不到字段，往往第一反应是 Apache 出问题，其实 90% 情况下是 post_max_size 或 upload_max_filesize 设得太小，尤其在上传文件或提交大量文本（如富文本编辑器内容）时极易触发。
检查方式很简单：在 PHP 脚本开头加一行 var_dump($_POST, $_FILES);，如果输出为空数组且没有报错，就基本锁定是大小限制问题。
确认并修改 post_max_size 和 upload_max_filesize
这两个值必须同时满足业务需求，且有依赖关系：post_max_size 必须 ≥ upload_max_filesize（否则上传字段直接被 PHP 丢弃），也必须 ≥ 所有 POST 字段总长度（含文件名、字段名、边界符等额外开销，实际可用约比设定值小 10%）。
- 用
phpinfo()查看当前生效的配置路径和值，重点关注 “Loaded Configuration File” 行 - 编辑对应
php.ini文件（不是 Apache 的httpd.conf） - 修改两行（例如支持 20MB 表单）：
post_max_size = 20M<br>upload_max_filesize = 15M
- 改完必须重启 PHP-FPM（若用 FPM）或 Apache（若用 mod_php），仅 reload 不生效
Apache 的 LimitRequestBody 真的需要调吗？
绝大多数场景下不需要碰这个指令。它作用于整个请求体（包括 POST + 文件 + multipart boundary），默认为 0（无限制），只有在明确要防 DoS 攻击、且已确认 PHP 层没拦住恶意大请求时才考虑设上限。设错反而会优先于 PHP 配置拦截请求，导致错误日志里只看到 Apache 的 413 错误，而看不到 PHP 的警告。
立即学习“PHP免费学习笔记（深入）”；
如果真要设，务必保证其值 ≥ post_max_size，否则 PHP 根本没机会执行。示例（写在虚拟主机或目录配置中）：
LimitRequestBody 25000000（单位是字节，25MB）
调试时容易忽略的三个点
很多排查卡在细节上：
-
memory_limit过小也会导致 POST 解析失败——PHP 在解析 multipart 时需内存暂存数据，建议设为至少post_max_size的 2 倍 - 使用 Nginx + PHP-FPM 时，还要检查 Nginx 的
client_max_body_size，它和 Apache 的LimitRequestBody是同级限制 - 某些 CDN 或 WAF（如 Cloudflare）会主动拦截超大 POST 请求，返回 400/413，此时 PHP 日志完全空白，需查边缘网关日志
最稳妥的验证方式：用 curl -X POST -F "data=@large_file.txt" http://yoursite.com/test.php 模拟真实提交，再看响应和日志。别只靠浏览器表单测试——浏览器缓存、重定向、编码差异都可能掩盖真实问题。
