PHP parse_url 没有 scheme 时为什么把主机当路径

在 PHP 里把 example.com/docs 交给 parse_url()，很多人会期待得到 host=example.com、path=/docs。实际情况是：没有 scheme，也没有开头的 // 时，这个字符串更像一个相对路径，example.com/docs 可能整体落在 path 中。要让它表达“没有 scheme 的主机”，应使用网络路径引用 //example.com/docs，或在进入解析前按业务规则补齐 scheme。

官方文档：https://www.php.net/manual/en/function.parse-url.php

核心判断：parse_url() 不会凭域名外观猜测 host。https://host/path 有 scheme，//host/path 有 authority 的引导符；只有 host/path 时，通常应按相对路径处理。它是拆分器，不是 URL 合法性校验器。

parse_url 为什么不会把域名外观当成主机

不少PHPer日常调用`parse_url`解析地址的时候都踩过这个坑：传入不带http/https这类协议头的域名字符串，比如`www.example.com/path`，解析结果里的host字段是空的，原本预期的主机名直接被归到了path的开头，后续逻辑很容易出异常。

这是因为`parse_url`的底层实现严格遵循RFC 3986的URI通用解析规则，没有前置scheme标识的字符串，会优先被判定为相对路径格式，自然不会拆分出独立的主机字段。

URL 的层次结构不是“第一个斜杠前的文本就是域名”。对常见绝对 URL 来说，scheme 后的 // 引出 authority，authority 中才包含 host。比如 https://example.com/docs 可以拆成 scheme、host 和 path。

而 example.com/docs 没有 scheme，也没有 // 这个网络路径引用标记。解析器没有足够语法依据把 example.com 提升为 host，因此把它作为相对路径的一部分更符合输入形态。这里的“路径”不是说它一定能访问成功，而是说返回数组的组件归类如此。

输入	主要字段	适合的解释
example.com/docs	path	相对路径候选，不自动猜 host
//example.com/docs	host、path	省略 scheme 的网络路径引用
https://example.com/docs	scheme、host、path	完整绝对 URL

三种写法放在一起，差异就很清楚

下面的例子只观察返回数组的字段，不把输出当作 URL 验证结果。代码中的中文注释标出每个输入想表达的语义。

 'example.com/docs',       // 普通相对路径候选
    'network' => '//example.com/docs',   // 没有 scheme，但明确引出 authority
    'absolute' => 'https://example.com/docs', // 完整绝对 URL
];

foreach ($samples as $name => $value) {
    // 保留原始输入，便于日志和后续错误提示定位。
    $parts = parse_url($value);
    echo $name, ': ', json_encode($parts, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE), PHP_EOL;
}
?>

plain: {"path":"example.com/docs"}
network: {"host":"example.com","path":"/docs"}
absolute: {"scheme":"https","host":"example.com","path":"/docs"}

这个对比解释了标题中的现象：不是 PHP 把一个已经识别出的 host 改成 path，而是第一个输入从语法上就没有给出 host 所需的上下文。网络路径引用则明确使用 //，所以可以得到 host，但 scheme 仍然为空。

先约定输入，再决定是否补 scheme

实际项目中常见三类输入：只允许完整 URL；允许 //cdn.example.com/a.js 这样的网络路径引用；或者允许站内相对路径。三者不能用同一条“解析后取 host”逻辑混过去，否则空 host 可能被当成异常，也可能被错误放行。

如果业务明确允许网络路径引用，可以补上一个已知协议再进入后续请求；如果业务只接受外部绝对 URL，则直接拒绝无 scheme 的输入更安全。下面的函数选择“只接受绝对 URL 或显式网络路径引用”的契约，并在返回值上做最小检查：

归一化不是万能过滤器。若还要限制域名，应对解析后的 host 做大小写、端口、国际化域名和允许列表处理，并让真正发起请求的组件使用相同的 URL 语义。PHP 手册特别提醒，不同标准的解析器混用可能造成安全问题。

什么时候应该换成 Uri\Rfc3986\Uri

parse_url() 适合兼容旧代码、读取一个已知格式地址的组件，或只需要把字符串拆成几个字段。但它不遵循某一个完整的 URL 标准，也接受部分和畸形输入。PHP 当前手册把 Uri\Rfc3986\Uri 与 Uri\WhatWg\Url 作为严格标准语义的方向；前者在 PHP 8.5+ 可用。

迁移时不要只把函数名替换掉。先列出旧代码允许的输入，再为 host/path、//host/path、带端口、空 query 和 fragment 等边界建立测试，确认新解析器的异常或空值处理符合调用方预期。若旧系统必须保留 parse_url() 的历史结果，就在边界处显式记录兼容原因。

常见问题

没有 scheme 时，给字符串前面加两个斜杠就一定正确吗？

不一定。只有当原始字符串确实代表网络路径引用时才适合这样做；站内路径或普通文件名不能被强行当成域名。

parse_url() 返回 false 就说明 URL 不安全了吗？

不是。false 只表示严重解析失败；能返回数组也不代表通过了域名白名单、协议限制或跳转安全检查。

为什么不能直接用字符串拼接判断 host？

端口、用户信息、IPv6 字面量、编码和相对引用都会改变边界。应先明确 URL 标准和业务输入契约，再用同一解析语义完成判断与请求。