$_GET仅读取URL查询参数，$_REQUEST默认合并$_GET、$_POST、$_COOKIE但来源模糊；应显式使用$_GET等超全局变量或filter_input()，避免$_REQUEST导致的安全与维护风险。
$_GET 只读取 URL 查询参数
$_GET 是 PHP 预定义的超全局数组，**仅包含通过 HTTP GET 方法提交的 URL 查询字符串（query string）中的键值对**。它不关心请求方法是否真的是 GET，只看数据是否出现在 URL 的 ?key=value&foo=bar 部分。
常见错误现象：
– 表单用 method="POST" 但手动在 URL 后拼了 ?id=123，$_GET['id'] 仍能取到 —— 这不是 bug，是设计如此；
– 用 file_get_contents('php://input') 或原生读取 body 时，$_GET 依然存在，但它和 body 无关。
使用建议：
– 用于获取分页参数（page、limit）、搜索关键词（q）、资源 ID（id）等无副作用的读操作；
– 不要用来接收密码、token、大量文本或敏感字段 —— 它会明文暴露在 URL、服务器日志、代理缓存中；
– 注意 URL 长度限制（通常 2KB 左右），过长会导致截断或 414 错误。
$_REQUEST 默认合并 $_GET、$_POST、$_COOKIE
$_REQUEST 是一个“混合容器”，默认包含 $_GET、$_POST 和 $_COOKIE 的并集。它的实际内容由 PHP 配置项 variables_order 决定（默认是 "GPC"，即 Get/Post/Cookie）。
立即学习“PHP免费学习笔记（深入）”；
关键细节：
– 如果 variables_order = "PGC"，则 $_POST 的同名键会覆盖 $_GET 的；
– 如果 variables_order = "CGP"，$_COOKIE 的值可能意外覆盖表单输入；
– 它不包含 $_FILES、$_SERVER 或 $_SESSION；
– $_REQUEST 是可写的（PHP 允许赋值），但这会污染原始来源，极不推荐。
性能与风险：
– 每次访问 $_REQUEST['x']，PHP 都需按顺序检查多个数组，开销略高于直接查 $_GET 或 $_POST；
– 在安全审计或调试时，你无法一眼判断某个值究竟来自 URL、表单还是 Cookie —— 这会让漏洞排查变模糊；
– 某些主机禁用 $_REQUEST（设为 variables_order = "GP" 或更少），导致依赖它的代码直接报错。
什么时候该用 $_GET 而不是 $_REQUEST
当逻辑明确依赖「URL 参数」本身时，必须用 $_GET。
典型场景：
– 生成分享链接（如 /article.php?id=42&ref=twitter），ref 必须来自 URL，不能被 POST 数据或 Cookie 替换；
– RESTful 接口的路径参数解析（配合 parse_url() + $_GET 处理 query）；
– 判断是否为首次访问（!isset($_GET['step'])），若混用 $_REQUEST，用户带 Cookie 可能绕过判断；
– 使用 filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT) 做类型过滤 —— filter_input 的 INPUT_GET 源头明确，比 $_REQUEST 更可控。
为什么多数情况下应避免 $_REQUEST
它掩盖了数据来源，让代码行为变得隐式且不可预测。
容易踩的坑：
– 开发时本地测试一切正常，上线后因用户 Cookie 中存在同名字段（如 theme=dark），导致表单提交的 theme=light 被忽略；
– 安全扫描工具标记 $_REQUEST 为高风险输入源，因为无法区分可信（如内部 Cookie）和不可信（如任意 URL 参数）；
– 框架（Laravel、Symfony）和现代 PHP 应用几乎从不使用 $_REQUEST，它们强制显式声明输入来源（$request->query() / $request->post()）；
– 升级 PHP 版本或切换 SAPI（如从 Apache mod_php 到 PHP-FPM）时，variables_order 行为差异可能引发静默故障。
替代方案：
– 显式使用 $_GET、$_POST 或 $_COOKIE；
– 用 filter_input() 指定输入类型，例如 filter_input(INPUT_POST, 'email', FILTER_SANITIZE_EMAIL)；
– 封装一层请求类，统一校验、过滤、转换，而不是靠 $_REQUEST “碰运气”。
真正复杂的点不在语法，而在于：一旦你习惯写 $_REQUEST['user_id']，就很难再回退去思考这个 ID 到底该不该被 Cookie 修改、该不该记录在访问日志里、该不该参与 CSRF 校验 —— 这些决策，都藏在那个看似方便的数组背后。
