优先用$_server['request_uri']获取完整请求路径(含查询参数),$_server['php_self']仅返回脚本路径但可能被path_info污染;二者均需htmlspecialchars()过滤防xss,拼全url须手动组合协议、域名与端口。

$_SERVER['REQUEST_URI'] 和 $_SERVER['PHP_SELF'] 到底该用哪个
要拿当前完整请求路径(含查询参数),优先用 $_SERVER['REQUEST_URI'];如果只想拿到脚本自身路径(不含 query string),$_SERVER['PHP_SELF'] 更安全,但它可能被恶意构造的 PATH_INFO 污染。
-
$_SERVER['REQUEST_URI']是最接近浏览器地址栏内容的值,比如访问/user/profile?id=123,它就返回/user/profile?id=123 -
$_SERVER['PHP_SELF']只返回当前执行脚本的路径部分,比如在/var/www/html/user/profile.php中,它通常返回/user/profile.php,但若 URL 是/user/profile.php/attack?xss=1,它可能变成/user/profile.php/attack—— 这就是注入风险点 - 不要直接输出这两个变量到 HTML,必须过
htmlspecialchars(),否则 XSS 一触即发
拼出完整 URL 需要手动补协议和域名
$_SERVER 里没有现成的“完整 URL”字段,HTTP_HOST 和 HTTPS 状态得自己组合。
- 用
$_SERVER['HTTP_HOST']拿域名(如example.com),但不保证有端口;需要端口时看$_SERVER['SERVER_PORT'],非标准端口才加 - 判断 HTTPS:检查
$_SERVER['HTTPS'] === 'on'或$_SERVER['SERVER_PORT'] == 443,但后者不可靠(有些代理会改端口) - 常见错误是硬写
http://,结果 HTTPS 页面里生成了混合内容警告 - 示例拼接:
$scheme = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on') ? "https" : "http"; $host = $_SERVER['HTTP_HOST']; $uri = $_SERVER['REQUEST_URI']; $full_url = $scheme . '://' . $host . $uri;
$_SERVER 数组不是所有键都一定存在
像 HTTP_REFERER、HTTP_X_FORWARDED_FOR、HTTPS 这些字段,取决于客户端是否发送、中间代理是否透传、服务器配置是否启用 —— 直接读取会触发 Notice: Undefined index。
- 必须用
isset()或filter_input(INPUT_SERVER, 'HTTP_REFERER')安全读取 -
REMOTE_ADDR可信度最低:经过 CDN 或反向代理后,它只是代理 IP;真实用户 IP 得查X-Forwarded-For,但这个头可伪造,不能用于鉴权 - 开发环境常缺
REQUEST_URI(尤其 CGI 模式),可用parse_url($_SERVER['SCRIPT_NAME'] . '?' . $_SERVER['QUERY_STRING'])回退
重写规则下 $_SERVER 值可能和预期不一致
Apache 的 RewriteRule 或 Nginx 的 try_files 会改变 $_SERVER 中多个字段,尤其是 SCRIPT_NAME、PHP_SELF、REQUEST_URI 的对应关系。
- Nginx 默认不设置
REQUEST_URI,需显式加fastcgi_param REQUEST_URI $request_uri; - Apache mod_rewrite 后,
PHP_SELF可能变成重写前的原始路径,而REQUEST_URI是重写后的,二者不一致是常态 - 做路由分发时,别依赖
PHP_SELF判断当前模块,用REQUEST_URI+ 自定义解析更可靠
真正麻烦的从来不是“怎么取”,而是“取出来之后敢不敢信”。每个 $_SERVER 键背后都有 N 种环境变量、代理链、重写规则在悄悄改它。信之前,先 var_dump() 看一眼实际值。
php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!











