最简组合是$_SERVER['HTTP_HOST']和$_SERVER['REQUEST_URI']，前者获请求Host（含端口），后者获完整路径与查询参数；注意HTTP_HOST可能为空需fallback至SERVER_NAME，反向代理需确保转发Host头。
用 $_SERVER['HTTP_HOST'] 和 $_SERVER['REQUEST_URI'] 拿最简组合
PHP 里最直接、兼容性最好的方式就是这两个超全局变量。前者返回客户端实际请求的 Host（含端口，如 example.com:8080），后者返回完整请求路径和查询参数（如 /path/to/page.php?x=1&y=2）。注意：HTTP_HOST 依赖请求头，若被篡改或缺失，可能为空——这时得 fallback 到 SERVER_NAME。
-
HTTP_HOST是用户浏览器发来的 Host 头，更贴近真实访问地址；SERVER_NAME是服务器配置值，更稳定但未必反映用户所见域名 - 如果用了反向代理（如 Nginx + PHP-FPM），确保 Nginx 转发了
Host头：proxy_set_header Host $host; - 不推荐拼接
$_SERVER['HTTPS']来构造完整 URL，因为协议判断容易出错（比如 CDN 后端仍是 HTTP）
需要带协议的完整 URL？别硬拼，先判断 HTTPS 是否真实生效
很多人一上来就写 ($_SERVER['HTTPS'] ?? '') === 'on' ? 'https://' : 'http://'，但这在负载均衡或容器环境下大概率失效——后端 PHP 看到的永远是 HTTP，而真实 HTTPS 由前端终止。正确做法是检查代理传来的头：
- 常见可信头：Nginx 通常设
proxy_set_header X-Forwarded-Proto $scheme;，读取$_SERVER['HTTP_X_FORWARDED_PROTO']更可靠 - 若同时存在多个代理头（如
X-Forwarded-Proto和Front-End-Https），优先按运维约定选一个，避免混用导致逻辑错乱 - 本地开发时这些头不存在，直接用
$_SERVER['SERVER_PORT'] == 443辅助判断，但仅限无代理场景
parse_url() 不适合实时提取，它解析的是字符串而非当前请求上下文
有人试图对 $_SERVER['REQUEST_URI'] 用 parse_url() 提取 path 或 query，这没问题；但若想靠它还原“域名”，就会掉坑——REQUEST_URI 根本不含域名信息。同样，parse_url('http://a.b/c') 是可行的，但你不能拿 $_SERVER['REQUEST_URI'] 去喂它指望得到 host。
-
parse_url()的用途是解析已知 URL 字符串，不是替代$_SERVER变量 - 如果真要组装完整 URL，应分别取协议（来自
X-Forwarded-Proto）、域名（HTTP_HOST）、路径（REQUEST_URI），再拼接 - 拼接时注意
REQUEST_URI开头自带/，别重复加斜杠
CLI 环境下 $_SERVER 不可用，别在命令行脚本里硬用
运行 php script.php 时，$_SERVER['HTTP_HOST'] 和 $_SERVER['REQUEST_URI'] 都不存在，会触发 notice。如果你的代码既要跑 Web 又要跑 CLI（比如定时任务调用同一逻辑），必须提前判断运行模式：
立即学习“PHP免费学习笔记（深入）”；
- 用
php_sapi_name() === 'cli'或!isset($_SERVER['HTTP_HOST'])做守卫 - CLI 场景下“域名”和“URI”没有意义，应由配置文件或参数传入模拟值，而不是试图从空数组里硬捞
- 框架项目（如 Laravel）通常封装了 request 对象，比直读
$_SERVER更健壮，但底层仍依赖这些变量——所以问题本质没变
真正麻烦的不是怎么取，而是不同部署环境对 $_SERVER 的污染程度不同。哪怕一行 echo $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];，在 Docker + Traefik + PHP-FPM 组合里也可能因头转发遗漏而崩。每次上线前，最好在目标环境里 var_dump(array_keys($_SERVER)); 确认关键键名是否存在。
