$_POST与$_GET用法详解_php表单接收

本文深入剖析了PHP中通过$_POST和$_GET安全接收表单数据的核心实践，强调绝不能直接使用未经验证的超全局变量——必须严格遵循“先判断存在性（isset或空合并）、再按类型过滤（如filter_input处理用户名、原样保留密码交由password_hash加密）、最后上下文转义输出（如htmlspecialchars防XSS）”的三步铁律；同时揭示$_GET因URL暴露性更易引发乱码与XSS风险，指出$_POST与$_GET互不覆盖但$_REQUEST潜藏配置陷阱，并反复警示：表单安全的关键不在取值本身，而在于对每个参数实施精准的类型校验、内容净化和上下文适配，一步疏漏就可能打开攻击大门。

PHP 用 $_POST 和 $_GET 接收表单数据，但直接读取不校验会出安全问题、乱码、空值崩溃——必须先判断存在性、过滤内容、转义输出。

怎么安全地从 $_POST 读取用户名和密码

用户提交登录表单后，$_POST['username'] 和 $_POST['password'] 不一定存在，也不可直接拼 SQL 或 echo 输出。

• 用 isset() 或 array_key_exists() 判断键是否存在，避免 Notice 错误
• 用 filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING) 过滤字符串（PHP 8.1+ 已弃用 FILTER_SANITIZE_STRING，改用 FILTER_SANITIZE_FULL_SPECIAL_CHARS 或手动 trim() + htmlspecialchars()）
• 密码绝不做任何“过滤”，只用 isset($_POST['password']) ? $_POST['password'] : '' 原样取值，后续交给 password_hash() 处理
• 示例：

  $username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_FULL_SPECIAL_CHARS) ?: '';
  $password = $_POST['password'] ?? '';

为什么 $_GET 比 $_POST 更容易出乱码和 XSS

$_GET 数据来自 URL，天然暴露、长度受限、编码不可控；浏览器地址栏粘贴、分享链接时可能带非法字符或未编码空格/中文。

• URL 中的中文若未用 urlencode() 编码，PHP 接收到的 $_GET 值可能是乱码（尤其在 Apache + mod_php 环境下）
• $_GET 内容应默认视为“不可信输入”，哪怕只是分页参数 ?page=2，也要用 filter_var($page, FILTER_VALIDATE_INT) 校验
• 绝不能把 $_GET['q'] 直接插入 HTML：

  搜索结果：

  —— 这是典型 XSS 入口
• 正确做法：

  $q = htmlspecialchars($_GET['q'] ?? '', ENT_QUOTES, 'UTF-8');
  echo "
  搜索结果：{$q}
  ";

$_POST 和 $_GET 同名字段会互相覆盖吗

不会。PHP 中 $_POST 和 $_GET 是两个完全独立的超全局数组，同名键互不影响。但如果你用 $_REQUEST，它默认合并了 GET、POST、COOKIE（顺序由 request_order 配置决定），这就容易踩坑。

• 检查 php.ini 中 request_order = "GP"（默认），表示 $_REQUEST 优先取 GET，再取 POST；若设为 "PG"，则 POST 会覆盖 GET 同名项
• 强烈建议永远不用 $_REQUEST，显式写 $_POST 或 $_GET，避免逻辑被配置悄悄改变
• 表单 method="get" 时，不要在 URL 上再手动拼 ?id=123，否则 $_GET 会出现重复键（如两个 id），PHP 只保留最后一个

真正麻烦的不是“怎么取值”，而是“取完之后怎么确保它没被篡改、没含恶意脚本、没破坏数据库查询”——每个 $_POST 或 $_GET 键都应该有明确的类型预期、过滤策略和上下文转义方式，少一步都可能让整个表单变成攻击入口。

到这里，我们也就讲完了《$_POST与$_GET用法详解_php表单接收》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！