配置项里有时写URI，有时写URL；浏览器地址里还会出现查询参数和#fragment。这些词值得分清，但仅靠“身份证、家庭住址”几个比喻，很难判断程序最终会请求什么。

更实用的顺序是：先确定采用哪套语法和解析规则，再看这个标识符怎样被应用使用。

URI是通用概念，URL强调访问机制

按RFC 3986的表述，URI是标识资源的通用形式；URL指其中同时提供主要访问机制的那一类。一个标识符可以具有名称、定位符或两者的特征，不宜再画成URL与URN严格互斥的两只盒子。RFC 3986第1.1.3节

现在的Web平台规范还有自己的用词背景：WHATWG URL标准统一使用URL这个词，并定义浏览器相关的解析与序列化规则。讨论某个库或字段时，应结合它依据的规范，而不是只争名字。WHATWG URL

几种引用可以这样读：

示例	说明
https://example.com/docs?lang=zh#install	一个HTTPS地址，包含主机、路径、查询与片段
urn:example:book-42	使用示例命名空间的URN语法例子，不表示这里真有一本可下载的书
data:text/plain,hello	内联数据的URL例子，没有HTTP地址那样的主机部分
../guide	相对引用，需要基准地址才能确定完整目标

方案名scheme也不总等于一种网络传输协议。不能要求每个URI都具备host:port，再把不符合HTTP地址外形的字符串都判成错误。

拆开一个HTTPS地址

https://example.com:8443/docs/page?lang=zh#install

部分	这个例子的值
scheme	https
主机	example.com
显式端口	8443
path	/docs/page
query	lang=zh
fragment	install

这里的path是服务端资源命名的一部分，不一定对应磁盘文件。query怎样解释，由相应应用决定；也不能把任意查询字符串都默认当成同一种键值表协议。

fragment则需要单独看：浏览器获取这个HTTP资源时，请求目标包含路径和查询，不会把#install作为HTTP请求目标发给服务器。片段由客户端按资源类型或应用规则解释，例如定位文档中的元素。RFC 3986片段规则

这是组件处理方式的示意，不是抓包记录。如果前端代码主动读取fragment后另发请求，那是应用新增的行为，不是HTTP自动携带片段。

URN描述命名，不保证浏览器能直接打开

URN使用urn方案，并在相应命名空间中分配名称。简化地看，其核心形式是：

urn:命名空间标识:命名空间内的标识

它的设计目标是持久、位置无关的资源标识。具体名称怎样管理、能否解析到某个访问地址，需要相应命名空间及解析机制支持。不能从“这是URN”推导出资源永久在线，或任意浏览器都知道怎样下载。RFC 8141

同样，资源可以有多个标识；一个地址的响应内容也可能随时间或内容协商变化。标识和定位提供了访问依据，不等于一次访问必定成功。

相对引用为什么需要关注最后的斜杠

按照Web URL的解析规则：

基准：https://example.com/docs/
引用：guide
结果：https://example.com/docs/guide

基准：https://example.com/docs
引用：guide
结果：https://example.com/guide

第二组基准路径的最后一段是docs，解析相对引用时会被新的路径段替换；第一组以斜杠结尾，guide追加到该路径下。检查页面相对链接，或显式使用URL解析器的接口基址时，需要注意这个差别；具体代理软件或客户端库若采用自己的拼接规则，还应另外核对。

实际代码中应使用对应平台的URL解析器处理基准、组件与编码，再核对结果。不要先随意解码整个字符串，再用几个字符串切割操作猜测边界。URL解析规则

修订于2026年11月1日：聚焦URI/URL/URN与相对引用，移除聊天残留，修正片段传输及标识、访问之间的边界。