在Web开发、接口文档甚至日常交流中，URL、URI、URN这三个词出现的频率非常高，但很多人对它们的理解其实是一知半解。有人认为URL就是网址，URI也是网址，两者没什么区别；也有人以为URN是已经被淘汰的旧技术。这些说法都对了一半，又都不完全对。要真正弄清楚，需要从定义层面开始梳理，再看它们之间的结构关系，最后结合实际应用场景来判断在什么情况下该用哪一个。
从定义入手：URI是统称，URL和URN是分支
URI的英文全称是Uniform Resource Identifier，即统一资源标识符。它的作用是唯一标识一个资源，注意这里的措辞是“标识”，而不是“定位”。标识的意思是，只要能通过某种方式把这个资源和其他资源区分开来，就达到了目的，至于通过这个标识能不能找到资源本身，URI并不强制要求。
URI下面分为两个主要的子类。第一个子类是URL，Uniform Resource Locator，统一资源定位符，它通过描述资源的位置来标识资源，比如资源在哪个服务器上、用什么协议访问、路径是什么。第二个子类是URN，Uniform Resource Name，统一资源名称，它通过一个持久的、与位置无关的名称来标识资源，典型的例子是图书的ISBN编号，一本书无论放在哪个图书馆、哪个网站，它的ISBN号是不变的。
用一个生活中的类比来理解：URI相当于“身份证号码”这个概念的总称；URL类似于“某某市某某区某某街道几号门牌”，靠地址找资源；URN则类似于人的姓名加出生编号这种持久标识，不管这个人搬到哪里，编号都跟着他。RFC 3986对URI的语法做了标准化定义，而URN的规范则在RFC 8141中有详细描述，这两份文档是理解该体系最权威的资料。
URI的通用语法结构拆解
按照RFC 3986的定义，一个完整的URI在语法上由多个部分组成，其通用格式可以表示为：scheme后面跟冒号，接着是分层部分，分层部分里可以包含授权信息、路径、查询字符串，最后可以带一个片段标识符。以一个常见的HTTP网址为例，https打头的部分是协议方案，www.ippipp.com是授权部分也就是主机名，后面的目录和文件名构成路径，问号之后的内容是查询参数，井号后面的部分则是片段，通常用来定位页面内的某个锚点。
理解这个结构的关键在于，URI的语法是统一的，任何符合这个语法的字符串都是一个合法的URI。而URL和URN只是URI在不同语义方向上的具体用法。也就是说，你平时在浏览器地址栏里输入的网址，既是URL，同时也是URI，因为URL必然是URI的一种。
还有一个细节值得注意：URI中允许出现的字符是有严格规定的，比如空格、中文等非保留字符必须经过百分号编码才能出现在URI里。这也是为什么在地址栏输入中文关键词时，浏览器会自动把它转成一串百分号开头的编码。
URL与URN的多维度对比
为了更直观地看出两者的差别，下面从几个关键维度做一次对比。
| 对比维度 | URL | URN |
|---|---|---|
| 核心作用 | 定位资源，告诉你在哪里能获取到它 | 命名资源，给它一个持久不变的身份 |
| 结构特征 | 包含协议方案、主机名、路径等定位信息 | 以urn开头，后跟命名空间标识符和具体名称 |
| 典型例子 | https://www.ippipp.com/page.html | urn:isbn:9787111558422 |
| 稳定性 | 资源移动或域名变更后可能失效 | 与位置无关，理论上永久有效 |
| 主要应用 | Web页面、API接口、静态资源访问 | ISBN书号、XML命名空间、持久数字对象标识 |
从这个表可以明显看出，URL的最大优势是可直接访问，浏览器拿到URL就能发请求，缺点是脆弱，服务器迁移、域名更换都会让原有的URL变成死链。URN恰恰相反，它不依赖任何位置，名称一旦确定就长期有效，但URN本身不能直接用于访问，需要借助解析系统把名称转换成实际的获取途径。
实际开发中该如何选择
绝大多数日常场景下，你打交道的基本都是URL。写网页链接、配置接口地址、设置资源跳转，用的都是URL。在技术文档中如果不确定该用哪个词，说URI是最稳妥的，因为它涵盖了所有情况，逻辑上不会出错。
需要用到URN的场景相对特定。比如XML文档中声明命名空间时，那串看起来像网址的字符串本质上就是持久标识符，很多规范推荐用URN形式来保证长期稳定。再比如学术出版领域，DOI这类持久标识体系的思想来源就与URN一脉相承，目的是让文献即使换了托管平台，标识依然不变。
还有一个容易混淆的场景是HTTP状态码和重定向设计。如果站点资源永久迁移，标准做法是返回301并把新地址告诉客户端，这背后体现的正是URL“会失效”这个固有缺陷，而URN体系的设计初衷就是为了解决这类问题，只是由于解析基础设施普及度有限，URN始终没有在普通Web浏览场景中大规模铺开。
常见误区与注意事项
第一个常见误区是把URI和URL当成并列关系。正确的理解是包含关系：所有URL都是URI，所有URN也都是URI，但URI不一定非得是URL或URN，规范中还存在同时具备定位和命名特征的混合形式，RFC 3986实际上淡化了两者的严格边界，把URL和URN更多视为对URI功能的描述性分类。
第二个误区是认为URN已经过时无用。事实上URN至今仍活跃在ISBN、ISSN等标准编号体系以及部分文档规范中，只是普通用户感知不到而已。判断一个标识符是不是URN，最简单的方法是看它是否以urn这三个字母开头并且带有冒号分隔的命名空间。
第三个注意事项涉及编码和特殊字符处理。在实际开发中拼接URI时，务必对参数值进行正确的编码，否则空格、井号、问号等字符会破坏URI结构，导致解析出错。同时建议在文档写作中保持术语准确：说到可点击访问的地址用URL，说到概念统称用URI，说到持久名称用URN，这样能大幅减少沟通歧义。
总结
简单概括三者的关系：URI是标识资源的大概念，URL靠位置标识，URN靠名称标识，它们是包含关系而非并列关系。日常开发中九成以上的场景用URL，文档表述拿不准时用URI不会错，而涉及持久标识需求时才需要考虑URN。把这三层关系理清楚之后，再面对技术文档和网络规范中的这些术语，就不会再产生混淆了。