PHP的$_GET无法获取含特殊符号的参数，主因是URL未正确编码；需前端用encodeURIComponent()或后端用rawurlencode()编码值，PHP自动解码无需再urldecode()，键名特殊字符会被转下划线，调试应先查Web服务器rewrite规则是否丢参。
PHP 中 $_GET 无法正确获取含特殊符号的参数？先检查 URL 编码
PHP 的 $_GET 数组本身不“丢失”参数，但若 URL 中的参数值含空格、中文、&、=、% 等字符却未编码，Web 服务器（如 Nginx/Apache）或 PHP 自身解析时会提前截断或误拆分。典型表现是：$_GET['q'] 只拿到一部分，或整个键名消失。
必须确保前端发起请求前已对参数值调用 encodeURIComponent()（JS）或 rawurlencode()（PHP 后端拼接时）。例如：
https://example.com/search?q=%E4%BD%A0%E5%A5%BD%20world%21
而不是：
https://example.com/search?q=你好 world!
- 空格 → 必须为
%20，不能是+（除非明确用application/x-www-form-urlencoded且服务端按 form 解析） - 中文、emoji、斜杠
/、问号?等均需rawurlencode()，不能只靠urlencode()（后者把空格转成+，在 GET 中易出错） - 如果用 cURL 或 JS
fetch构造 URL，请手动编码每个 value，不要依赖浏览器自动编码整个 URL 字符串
PHP 接收后是否还需 urldecode()？一般不需要
PHP 默认会对 $_GET 中的值自动执行 urldecode()（更准确地说，是 CGI SAPI 层做的解码），所以你直接读 $_GET['name'] 拿到的就是原始语义值（如 “你好 world!”），无需、也不应再套一层 urldecode() —— 否则会导致二次解码错误，比如 %2520（即 %20 被再编码一次）变成乱码或警告。
立即学习“PHP免费学习笔记（深入）”；
例外情况：
- 你用
file_get_contents('php://input')手动读取原始 Query String，则需自行parse_str(urldecode($raw), $output) - 某些老旧 Nginx 配置禁用了默认解码（极少见），此时
$_GET值仍是百分号编码态，才需要显式urldecode() - 若参数来自非标准入口（如 WebSocket 消息、日志回放 URL 字符串），而非真实 HTTP GET 请求，那它根本不在
$_GET里，别硬套
遇到 $_GET 键名含特殊符号（如点号、中括号）怎么办？
PHP 会自动将 URL 中的 .、[、] 等字符转换为下划线 _，这是历史遗留行为（受 variables_order 和 register_globals 影响）。例如：
https://example.com/?user.name=admin&data[0]=a
实际得到的是：
$_GET = ['user_name' => 'admin', 'data_0' => 'a'];
这不是 bug，是 PHP 的默认过滤逻辑。解决方法只有两个：
- 改用
$_SERVER['QUERY_STRING']手动解析：parse_str($_SERVER['QUERY_STRING'], $qs);，它保留原始键名（但要注意：仍需先确认该字符串是已解码态还是原始态） - 前端彻底避免在键名中使用
.和[]，改用下划线或连字符，比如user_name、data_0 - 不要试图用
ini_set('arg_separator.input', '&')来绕过 —— 它控制分隔符，不解决键名转换问题
调试时发现参数“有时有、有时没”，重点查 Nginx/Apache 的 rewrite 规则
很多看似 PHP 的问题，实则是 Web 服务器在转发前就吃掉了参数。尤其是 Nginx 的 rewrite 指令，若末尾没加 ?，会丢弃原始 query string：
rewrite ^/old/(.*)$ /new/$1 permanent; ← ❌ 丢弃所有 ?xxx
rewrite ^/old/(.*)$ /new/$1? permanent; ← ✅ 保留 query string
Apache 的 RewriteRule 同理，需加 [QSA] 标志（Query String Append）。
验证方式很简单：在 PHP 入口第一行加
error_log(print_r($_SERVER['QUERY_STRING'], true), 3, '/tmp/q.log');
然后对比访问日志中的原始请求 URL 和该日志内容，就能确定参数是在哪一层消失的。
真正棘手的永远不是 PHP 怎么读，而是参数压根就没进到 PHP 这一层。
