PHP获取当前完整URL的可靠写法是组合$_SERVER变量：用HTTPS或X-Forwarded-Proto判断协议，HTTP_HOST fallback SERVER_NAME获取域名，SERVER_PORT显式拼接非默认端口，REQUEST_URI补充路径与参数。
PHP 获取当前完整 URL 的可靠写法
直接拼接 $_SERVER 变量是最常用也最可控的方式，但必须注意协议、端口、代理等现实情况。很多网上抄来的“一行代码”在 HTTPS、反向代理或非标准端口下会出错。
-
$_SERVER['REQUEST_URI']只返回路径 + 查询参数（如/user/profile?id=123），不包含协议和域名，不能单独用作完整 URL - 判断协议要用
$_SERVER['HTTPS'] === 'on'或检查$_SERVER['HTTP_X_FORWARDED_PROTO']（Nginx/Apache 代理场景） - 端口不是总等于 80/443：如果
$_SERVER['SERVER_PORT']不是默认值，且 URL 显式写了端口（如:8080），就得带上 - 推荐组合：
$_SERVER['REQUEST_SCHEME']（PHP 5.5.7+）比手动判断更稳，但低版本需回退逻辑
兼容 PHP 5.3+ 的安全获取方式
下面这段代码能覆盖绝大多数部署环境（包括 Nginx + PHP-FPM、Apache、带 CDN 或负载均衡的场景）：
$protocol = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on') || (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') ? 'https' : 'http';
$host = $_SERVER['HTTP_HOST'] ?? $_SERVER['SERVER_NAME'];
$port = $_SERVER['SERVER_PORT'];
$request_uri = $_SERVER['REQUEST_URI'] ?? '/';
$url = $protocol . '://' . $host;
if (($protocol === 'http' && $port != 80) || ($protocol === 'https' && $port != 443)) {
$url .= ':' . $port;
}
$url .= $request_uri;
// $url 就是当前完整 URL
关键点：优先读 HTTP_HOST（防伪造）， fallback 到 SERVER_NAME；HTTP_X_FORWARDED_PROTO 必须显式检查，否则 HTTPS 请求经 Nginx 转发后会变成 http://
为什么 $_SERVER['PHP_SELF'] 和 $_SERVER['SCRIPT_NAME'] 不行
这两个变量只返回当前执行脚本路径（如 /index.php），不包含查询参数，也不反映重写后的 URL（比如 Laravel 的 /users/1 实际对应 /index.php）。它们本质是服务端路径，不是客户端看到的 URL。
立即学习“PHP免费学习笔记（深入）”；
-
$_SERVER['PHP_SELF']还可能被恶意注入（如/index.php/path%3Cscript%3E...），直接输出有 XSS 风险 - 若用了 URL 重写（.htaccess 或 nginx rewrite），
SCRIPT_NAME完全无法反映用户访问的真实路径 - 它们都不含
QUERY_STRING，而REQUEST_URI包含，这是核心差异
实际使用中容易忽略的坑
开发时本地测试一切正常，上线后 URL 拼错，大概率是这几个点没处理：
- Nginx 配置里没传
proxy_set_header X-Forwarded-Proto $scheme;，导致 PHP 拿不到真实协议 - CDN 或 WAF 层清除了
X-Forwarded-*头，此时只能依赖$_SERVER['SERVER_PORT']和硬编码协议（不推荐） -
HTTP_HOST可被客户端篡改，若用于生成跳转链接且未校验，可能引发开放重定向漏洞 - CLI 环境下
$_SERVER相关键名不存在，这段代码会报undefined index，需提前判断运行模式
真正稳定的方案，得结合部署架构来定——没有“一劳永逸”的单行函数，只有适配你当前服务器链路的写法。
