$_POST和$_GET完全独立，PHP不自动合并；同名参数需显式区分来源，优先使用$_GET或$_POST而非$_REQUEST，并注意filter_input不支持INPUT_REQUEST。
PHP中$_POST和$_GET不能混用，但可以同时读取
PHP不会自动合并或覆盖 $_POST 和 $_GET，它们是完全独立的超全局数组。所谓“混合值”，实际是你在URL里带了查询参数（触发 $_GET），又提交了表单（触发 $_POST），两者共存于一次请求中——PHP原生支持这种场景，无需特殊配置。
常见错误现象：
– 表单提交后发现URL参数丢失（其实是没手动保留）
– 误以为 $_REQUEST 总是包含全部，结果顺序被覆盖（默认 request_order = "GP"，即 $_GET 覆盖 $_POST 同名键）
– 直接用 $_REQUEST['xxx'] 而不确认来源，导致调试困难
- 始终优先显式使用
$_GET或$_POST，避免依赖$_REQUEST - 若需保留URL参数并提交表单，前端应在表单内补隐藏字段：
<input type="hidden" name="page" value="<?php echo htmlspecialchars($_GET['page'] ?? ''); ?>">
- 检查
php.ini中的request_order值（默认"GP"），它决定$_REQUEST的合并顺序，但不改变$_GET/$_POST本身
如何安全区分同名参数来自GET还是POST
当URL含 ?id=123，表单又提交了 id=456，你必须明确知道该用哪个值。PHP不做智能判断，全靠你写清楚。
- 直接读取：
$_GET['id']拿到123，$_POST['id']拿到456，互不干扰 - 不要用
isset($_REQUEST['id'])判断存在性——它只告诉你“有”，不告诉你“从哪来” - 如需按业务逻辑选值（例如“POST优先”），显式写：
$id = $_POST['id'] ?? ($_GET['id'] ?? null);
- 对用户输入始终过滤：
filter_input(INPUT_GET, 'id', FILTER_SANITIZE_NUMBER_INT)或filter_input(INPUT_POST, 'id', FILTER_SANITIZE_STRING)
$_REQUEST不是万能替代，慎用
$_REQUEST 是 $_GET、$_POST、$_COOKIE 的合并视图，但它不可靠：值来源模糊、受 request_order 控制、无法做类型化过滤（filter_input() 不支持 INPUT_REQUEST）。
立即学习“PHP免费学习笔记（深入）”；
- PHP 8.0+ 已标记
$_REQUEST为“可能被禁用”的功能，部分托管环境默认关闭 -
filter_input(INPUT_REQUEST, ...)不存在，想统一过滤就得分别调用两次 - 日志或调试时，打印
$_GET和$_POST分开看，比看$_REQUEST更快定位问题
实际传参混合场景的典型处理方式
比如分页列表带搜索表单：URL是 /list.php?page=2&sort=name，表单提交搜索关键词 q=php。你需要把 page 和 sort 带进新请求，同时提交 q。
- 后端不“自动传递”，你要显式构造：
$next_url = 'list.php?' . http_build_query(array_merge($_GET, $_POST));
（注意：这会把POST数据也拼进URL，仅适合GET型重定向） - 更常见的是表单method="post" + 隐藏字段，如前文所示
- AJAX提交时，可手动合并：
fetch('/list.php', { method: 'POST', body: new URLSearchParams({...Object.fromEntries(new URLSearchParams(window.location.search)), ...new FormData(form)}) }); - 永远验证
$_POST是否非空（!empty($_POST)），再决定是否处理表单逻辑，避免GET请求误触发写操作
