在准备个人网站或小型项目之前，你会遇到两个相关但不同的概念：域名和完整URL。混淆它们可能导致与协作者沟通出错，或者在建站设置时产生失误。本文用一个假设地址来展示各部分的作用，并演示如何记录你的理解以备后续参考。12
域名与完整URL分别回答什么问题
假设你正在规划一个小型个人项目，并写下了一个示例地址来测试自己的理解：https://example.org/notes/first-page?view=compact#intro。这个地址纯粹是假设的，仅用于拆解字符串，并不指向一个真实页面。第一次看到它时，你可能会好奇每一段在做什么，为什么有些部分看起来是可选的，而另一些似乎必不可少。
域名回答的问题是「我要访问互联网上的哪台服务器？」域名是互联网基础设施的关键组成部分，因为它们为互联网上任何可用的Web服务器提供了人类可读的地址。计算机通过IP地址进行通信，而IP地址对人类来说难以记忆且可能随时间变化，因此域名通过提供一个稳定、可读的标签来解决这个问题。1
完整URL回答的是一个更广泛的问题：「我想要那台服务器上的哪个具体资源，在什么条件下？」URL是互联网上唯一资源的地址，也是浏览器用来检索已发布资源（如HTML页面、CSS文档和图片）的关键机制之一。换句话说，域名标识了建筑物，而完整URL指定了具体的房间、楼层，甚至你正在寻找的那个特定书架。2
逐段标出示例地址的各个组成部分
现在取同一个假设字符串，逐段标出各部分。开头的https是方案（scheme），它告诉浏览器在请求资源时应使用哪种协议。对于网站来说，方案通常是HTTPS或其未加密版本HTTP。方案与下一部分之间的分隔符是字符组合://，其中冒号将方案与后续内容分开，双斜杠表示接下来是权限（authority）部分。2
本例中的权限部分是example.org。这就是域名，它指示正在请求哪台Web服务器。根据MDN的说明，域名通常是人类可读的名称，尽管IP地址也可以出现在这个位置；但在实践中，IP地址很少出现在这里，因为对人类来说远不如域名方便。2
权限部分之后是路径：/notes/first-page。路径指向Web服务器上的一个资源。在Web早期，这样的路径代表服务器上的物理文件位置，但如今它主要是由Web服务器处理的抽象概念，没有对应的物理实体。路径之后是一个问号，它引出查询字符串view=compact。查询参数是提供给Web服务器的额外键值对，服务器可以在返回资源之前利用它们进行额外处理。最后，井号引出片段标识符intro。锚点代表资源内部的一种「书签」，为浏览器提供指引，使其显示位于该书签位置的内容。值得注意的是，片段标识符不会随请求发送到服务器。2
保持主机不变，对比不同路径与查询
保持示例的主机部分不变，设想三种变体。第一种是https://example.org/notes/first-page，没有查询也没有片段。第二种是https://example.org/notes/second-page?view=compact，只改变了路径。第三种是https://example.org/notes/first-page?view=full#summary，保持相同路径但改变了查询值和片段。三者共享同一个域名，因此都会将浏览器引导到同一台服务器。
这三个字符串之间的差异完全在于路径、查询和片段部分。不同的路径指向该服务器上的不同资源。不同的查询值传递不同的参数，服务器是否使用这些参数取决于它自身的规则。不同的片段告诉浏览器在返回的资源中滚动到不同的书签位置。这些观察并不能告诉你服务器实际上对每种变体做了什么，它们只描述了字符串向浏览器传达的信息。
这种区分在你规划自己的网站时很重要。你可能会假设改变查询参数总是会产生视觉上不同的页面，但这完全取决于服务器的配置方式。同样，两个仅在片段上不同的URL通常会加载相同的资源，然后滚动到不同的位置。认识到URL的哪些部分影响发送给服务器的请求、哪些部分由浏览器在本地处理，能帮助你在测试或分享链接时避免混淆。
为假设项目制作一张地址说明卡
记录一张简短的说明卡，描述你的假设项目，在开始搭建之前完成。说明卡应包含四个字段：页面的目的、完整地址、各组成部分的拆解，以及你对任何不确定之处的备注。对于本文使用的示例，目的可以写成「以紧凑阅读模式展示的一篇练习笔记，锚定到引言部分」。完整地址就是字符串本身。拆解部分分别列出方案、域名、路径、查询和片段。
用平实的语言而非技术术语来记录目的。如果你之后将这张说明卡分享给一位没有Web开发背景的协作者，他们应该能够理解这个页面的用途，而不需要自己去解析URL。这个习惯在你撰写文档、提交问题报告，或者仅仅是在几个月后试图回忆为什么选择了某个特定结构时，都会派上用场。
在说明卡中加入一条关于任何不确定部分的简短备注。例如，你可以写「我不确定服务器是忽略view参数还是用它来切换布局」。明确标出不确定之处能防止你做出可能在以后导致错误的假设。说明卡是一份工作文档，不是最终规格说明，因此留下未解决的问题完全没问题。
手工核对说明卡
检查你的说明卡是否与原始字符串逐字对应。将完整URL复制到一个纯文本编辑器中，在每个边界前插入一个空格：在://前一个，在域名后的第一个/前一个，在?前一个，在#前一个。这种视觉分隔使你很容易看出拆解结果是否与实际字符串一致。
标注每个片段，直接写在分隔后的字符串上方或下方。在https下写「方案」，在example.org下写「域名」，在/notes/first-page下写「路径」，在view=compact下写「查询」，在intro下写「片段」。如果任何标签没有与某个片段清晰对齐，回去重新检查你放置空格的位置。
将标注后的版本与你在上一节写的说明卡进行对比。确认目的描述仍然与字符串实际表达的内容一致。如果发现不匹配，更新说明卡而不是字符串，因为字符串是本次练习的固定参照点。当所有内容对齐后，将分隔后的字符串和说明卡保存在同一个文件中，以便日后一起查阅。
步骤 1
将完整的假设URL复制到一个纯文本编辑器中。
步骤 2
在每个结构边界前插入空格：在://前、在第一个路径斜杠前、在问号前、在井号前。
步骤 3
在每个片段上方写出标签，标明它是方案、域名、路径、查询还是片段。
步骤 4
将标注后的片段与你的说明卡对比，修正说明卡上的任何不匹配之处。
保留说明供后续使用
将完成的说明卡存放在你开始撰写内容或配置网站时会自然再次看到的地方。项目文件夹中的一个简单文本文件就可以，但放在你已经用于项目规划的任何工具中的笔记同样可行。目标不在于格式，而在于养成一个有书面参考可查的习惯，而不是依赖记忆。
当你最终从假设示例转向真实项目时，用你的实际地址重复同样的练习。将真实URL写入相同格式的说明卡，拆解它，并标注每个部分。你很可能会发现第二轮花的时间更少，因为结构已经熟悉了。如果你的真实项目使用了不同的方案、子域名或额外的查询参数，同样的标注方法仍然适用。
将说明卡分享给协作者或将其保存在共享项目空间中，也能减少沟通误解。当有人问「这个URL是做什么的？」时，你可以指向拆解结果，而不是从头解释。随着时间推移，这些小型记录会积累成一份有用的项目参考资料库，尤其是当你管理多个页面或环境时。
常见问题
URL中的片段标识符会被发送到服务器吗？
不会。根据MDN的说明，片段标识符即井号之后的部分，不会随请求发送到服务器。浏览器在本地使用它来滚动到返回资源中的书签位置。2
域名可以不带路径单独出现在URL中吗？
可以。像https://example.org这样的URL包含方案和域名，但没有路径、查询或片段。路径及其之后的内容都是可选组成部分。仅凭域名就足以将浏览器引导到服务器。2
修改查询字符串一定会改变用户看到的内容吗？
不一定。查询参数是提供给Web服务器的，而每台服务器对如何处理这些参数有自己的规则。不同的查询值是否会产生视觉上不同的结果，完全取决于服务器配置，而不是URL字符串本身。2