应显式合并$_GET和$_POST：$input = array_merge($_GET, $_POST)，因$_REQUEST默认含$_COOKIE存在安全风险；需结合字段存在性、CSRF token及REQUEST_METHOD校验提交合法性，并通过_method字段兼容PUT/PATCH/DELETE。
PHP 如何统一处理 GET 和 POST 表单提交
PHP 本身没有自动合并 $_GET 和 $_POST 的机制，但多数表单兼容需求本质是「不关心 method，只关心参数是否存在」。直接用 $_REQUEST 最快，但它默认包含 $_COOKIE，可能引入意外覆盖或安全风险（比如攻击者伪造 cookie 覆盖同名参数）。
更稳妥的做法是显式合并：
$input = array_merge($_GET, $_POST);
注意：如果 GET 和 POST 同时含同名键，$_POST 的值会覆盖 $_GET（因 array_merge 后者优先）。这符合常见预期（如 POST 表单提交应以主体为准）。
判断实际提交 method 的可靠方式
不能只靠 $_SERVER['REQUEST_METHOD'] 就认定是表单提交——它也可能是 AJAX、curl 或浏览器直接 GET 访问。真正要区分「是否来自用户表单」，得结合业务逻辑判断：
立即学习“PHP免费学习笔记（深入）”；
- 检查关键字段是否存在，例如
isset($input['submit'])或!empty($input['email']) - 验证 CSRF token（推荐），如
hash_equals($_SESSION['csrf_token'], $input['token'] ?? '') - 对敏感操作（如删除、支付）强制要求
$_SERVER['REQUEST_METHOD'] === 'POST'，并拒绝 GET 请求
单纯依赖 method 判断是否“表单提交”不可靠；字段存在性 + token 验证才是实际防线。
处理 PUT/PATCH/DELETE 等非标准 method 的兼容写法
HTML 原生表单只支持 GET 和 POST，但后端常需兼容 RESTful 接口。常见做法是用 POST 携带 _method 字段模拟：
<form method="POST"> <input type="hidden" name="_method" value="PUT"> <!-- 其他字段 --> </form>
PHP 端可这样解析：
$method = strtolower($_POST['_method'] ?? $_SERVER['REQUEST_METHOD']);
if (in_array($method, ['put', 'patch', 'delete'])) {
parse_str(file_get_contents('php://input'), $raw_data);
$input = array_merge($input, $raw_data);
}注意：php://input 只能读一次，且在 Content-Type: application/x-www-form-urlencoded 时已被 PHP 自动解析进 $_POST，此时直接读会为空。所以务必先判断是否已由 _method 触发，再决定是否重读原始体。
$_REQUEST 的坑和替代方案
$_REQUEST 默认顺序是 GET、POST、COOKIE（由 php.ini 中 request_order 控制），但很多环境默认启用了 cookie，导致攻击者可通过 Cookie 注入同名参数干扰逻辑。
如果你只需要 GET+POST，禁用 $_REQUEST 的 cookie 部分更安全：
// 在入口文件开头设置（需 php >= 5.6）
ini_set('request_order', 'GP');或者干脆不用 $_REQUEST，始终用 array_merge($_GET, $_POST) 显式控制来源和优先级——代码意图清晰，调试时也容易追踪参数来自哪边。
真正复杂的兼容场景（比如多端混合提交、第三方回调、签名验证）往往需要按请求头、来源 IP、签名字段等维度做分流，而不是靠 method 统一兜底。
