PHP处理URL参数最易出错的是编码、拼接、接收三环节未对齐：urlencode()位置错误、http_build_query()遗漏、$_GET重复解码均致中文乱码；应统一UTF-8并避免手动拼接与二次编码。
PHP处理URL参数最常出问题的地方，不是不会写，而是编码、拼接、接收三个环节没对齐——urlencode()用错位置、http_build_query()漏掉、$_GET重复解码，三者任一出错，中文就变%E4%BD%A0或乱码。
拼查询参数时别手写 urlencode()
手动拼 "?name=" . urlencode($name) . "&city=" . urlencode($city) 看似可控，实际极易漏编码、错顺序、引号不闭合。尤其当值含数组、空值、特殊符号（如 &、=、+）时，字符串拼接直接失效。
-
http_build_query()自动对每个值调用urlencode()，支持嵌套数组（['tag' => ['php', 'web']]→tag[0]=php&tag[1]=web） - 键名不编码，所以确保键是 ASCII 字符（如
user_id可以，用户ID不行） - 不要在它外面再套一层
urlencode()，否则整个 query string 被二次编码，变成%3Fname%3D...
urlencode() 和 rawurlencode() 别混用
两者都支持 UTF-8 中文，但空格和保留字符处理逻辑不同，用错会导致路由 404 或参数解析失败。
- 拼查询参数（
?q=搜索关键词）→ 用urlencode()：空格转+，浏览器和 PHP 都能正确识别 - 拼路径段（
/user/张三）→ 必须用rawurlencode()：空格转%20，且不编码/、?、#等保留符 - 调第三方 API 时，看文档要求：要
%20就用rawurlencode()；要兼容 HTML 表单提交（application/x-www-form-urlencoded）就用urlencode()
接收端别对 $_GET 再调用 urldecode()
PHP 在请求进入时已自动对 QUERY_STRING 做了 urldecode()，$_GET['name'] 拿到的就是原始中文字符串。再解一次，% 开头的字节会被误当作编码前缀，导致数据损坏。
立即学习“PHP免费学习笔记（深入）”；
- 唯一需要手动
urldecode()的场景：从$_SERVER['HTTP_REFERER']、自定义 header、或 POST body 中读取的原始 URL 字符串 - 如果
$_GET里还是乱码，问题不在解码函数，而在链路未统一 UTF-8：PHP 文件保存为 UTF-8 无 BOM、响应头header('Content-Type: text/html; charset=utf-8')、HTML 有<meta charset="utf-8">、数据库连接设utf8mb4
解析 URL 用 parse_url()，但别依赖它验证
parse_url() 是拆 URL 的标准工具，但它不校验合法性。传入相对路径、缺协议、多斜杠等“非标”输入，它仍会返回结果，只是字段可能为空或错位。
- 提取路径用
parse_url($url, PHP_URL_PATH)，提取参数用parse_url($url, PHP_URL_QUERY) - 若需判断 URL 是否有效，必须配合
filter_var($url, FILTER_VALIDATE_URL) - 注意：
parse_url()返回的数组值**未经解码**，比如query字段仍是name=%E4%BD%A0，不是你；如需进一步解析参数，得先用parse_str()
真正容易被忽略的是「编码源头」——不是函数选错，而是整个 HTTP 请求生命周期里，浏览器、Web 服务器（Nginx/Apache）、PHP、数据库，任意一环没设 UTF-8，中文就断在中间。调试时优先检查 Content-Type 响应头和文件保存编码，比翻函数文档更快定位问题。
