$_request 有时拿不到 post 数据是因为 php.ini 中 request_order 未包含 p（如设为 gp 或 gc），正确值应为 gpc；同名参数覆盖顺序由 request_order 决定；文件上传仅存于 $_files，不在 $_request 中；其性能开销更大且存在安全风险。
$_REQUEST 为什么有时拿不到 POST 数据
PHP 的 $_REQUEST 默认包含 $_GET、$_POST 和 $_COOKIE，但它的实际内容由 php.ini 中的 request_order 和 variables_order 共同决定。如果只看到 GET 和 COOKIE 数据，却读不到 POST，大概率是 request_order 里没写 P。
检查当前配置：
var_dump(ini_get('request_order'));
常见错误值是
GP（忽略 POST）或 GC（连 POST 字母都没放进去）。正确值应为 GPC 或至少含 P。
-
request_order = "GPC"是安全推荐值，明确控制合并顺序 - 不要依赖默认值——不同 PHP 版本/发行版默认不同（如某些 Debian 包默认是
GP） - 修改后必须重启 PHP-FPM 或 Web 服务器，
ini_set()对该配置无效
$_REQUEST 和 $_POST 冲突时以谁为准
当同名参数同时出现在 URL 查询串和 POST body 中（比如 ?id=1 且 POST 提交了 id=2），$_REQUEST['id'] 的值取决于 request_order 中字母的先后顺序。顺序靠前的超全局变量会覆盖靠后的。
例如：request_order = "PGC" → $_POST 在前 → $_REQUEST['id'] 是 2；request_order = "GCP" → $_GET 在前 → $_REQUEST['id'] 是 1。
- 这种覆盖是静默发生的，不会报错或警告
- 调试时建议直接查
$_POST和$_GET，而非只看$_REQUEST - 表单提交中混用 GET 参数（如分页 + 表单）时，极易因覆盖导致逻辑错乱
用 $_REQUEST 接收文件上传数据？不行
$_REQUEST 完全不包含文件上传信息。所有上传文件都只存在于 $_FILES 中，且 $_FILES 永远不会被合并进 $_REQUEST，无论 request_order 怎么设。
常见误操作：
if ($_REQUEST['avatar']) { ... } // 错！文件名在 $_FILES['avatar']['name']，不在 $_REQUEST
- 判断是否有文件上传，必须检查
$_FILES['field_name']['error'] === UPLOAD_ERR_OK -
$_FILES是独立超全局变量，PHP 不允许它参与$_REQUEST合并 - 试图用
$_REQUEST统一处理“所有输入”时，文件字段天然被排除在外
$_REQUEST 的性能与安全性隐患
每次访问 $_REQUEST 都会触发一次三数组合并（按 request_order 顺序逐个拷贝键值），比直接读 $_POST 或 $_GET 多约 10%–15% CPU 开销（尤其在大量参数时）。更关键的是语义模糊：你永远不确定某个键来自哪里。
- CSRF 防御中，token 若从
$_REQUEST读取，可能被 GET 参数绕过（攻击者把 token 拼在 URL 上） - API 开发中禁止使用
$_REQUEST，必须显式声明来源（$_POSTfor JSON/form-data,$_GETfor query params） - 日志记录请求参数时，若只记
$_REQUEST，将丢失来源上下文，排查问题困难
真正需要“统一入口”的场景极少，多数时候只是图省事。而省下的那几行代码，换来的可能是线上排查两小时。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
