准备上线个人网站或小型项目时，你会频繁接触两个相关但不同的概念：域名和完整URL。混淆它们可能导致与协作者沟通出错或在文档中写错地址。本文用一个假设地址逐段拆解，展示每个部分的作用，并介绍一种简单的记录方法供你自己的项目参考。
域名与完整URL分别回答什么问题
假设你正在搭建一个小型阅读笔记项目，想把其中一页分享给朋友。你在浏览器中输入一个地址然后发送出去。你分享的这个地址是一个完整URL，但其中的域名和其余部分回答的是不同的问题。域名标识的是你想访问互联网上的哪台服务器。域名是为互联网上任何可用网络服务器提供的人类可读地址，因为计算机实际使用的数字IP地址对人类来说难以记忆，而且可能随时间变化。1
完整URL则更进一步。它是互联网上某个唯一资源的地址，不仅告诉浏览器要联系哪台服务器，还指明要从该服务器获取哪一项具体资源。URL由不同部分组成，有些是必需的，有些是可选的，它们合在一起为浏览器提供足够信息，使其能够获取某一个特定页面、图片或文档，而不仅仅是网站的主页。2
在我们的假设示例中，完整地址是 https://example.org/notes/first-page?view=compact#intro。这个地址纯粹是为了练习拆解字符串而编造的，并不指向一个真实存在的页面。记住这个前提之后，我们就可以逐段查看每个部分分别贡献了什么信息。
在示例地址中标出各个部分
第一个片段 https 是方案（scheme），它指示浏览器在请求资源时必须使用的协议。对于网站来说，协议通常是HTTPS或HTTP。在我们的示例中，https的存在告诉浏览器在联系服务器时使用安全版本的协议。2
下一个片段 example.org 是域名。它位于URL规范所称的权限（authority）部分内部，该部分通过字符组合 :// 与方案分隔。域名指示的是正在请求哪台网络服务器。域名的结构由若干部分组成，以圆点分隔并从右向左阅读。在 example.org 中，最右边的 org 是顶级域名，example 是位于其前面的标签。12
域名之后是路径 /notes/first-page。路径标识的是网络服务器上的资源。在我们的假设地址中，它暗示有一个名为 first-page 的页面位于名为 notes 的栏目内，不过这里我们只是在阅读字符串结构，并不对任何实际服务器行为做出断言。路径之后，问号引出查询字符串 view=compact。查询参数是提供给网络服务器的额外键值对，问号是标示其开始的分隔符。最后，井号引出片段标识符 intro。片段相当于资源内部的一个书签，为浏览器提供指令使其显示该书签位置的内容。值得注意的是，井号之后的部分也就是片段标识符，不会随请求一起发送给服务器。2
保持主机不变，对比不同路径与查询字符串
为了直观看到各部分的区别，保持主机部分 example.org 不变，只改变其余内容。设想第二个地址：https://example.org/notes/second-page?view=full。方案和域名完全相同，因此浏览器会联系同一台服务器。路径现在指向不同的资源，是 second-page 而非 first-page，查询参数的值也不同，是 full 而非 compact。这些都是纯粹的字符串层面观察，我们并不推断任何服务器实际会返回什么。
再考虑第三个变体：https://example.org/notes/first-page#summary。这里路径与原始示例相同，查询字符串不存在，片段从 intro 变为 summary。去掉查询字符串意味着问号后面不再附加额外参数，因为根本没有问号出现。改变片段会让浏览器在服务器为该路径返回的资源中定位到不同的书签位置。同样，这是对字符串结构的观察，不是对服务器行为的预测。
这些对比说明了一个有用的原则：域名在同一个站点的所有页面中保持不变，而路径、查询和片段则随着定位不同资源或资源内不同位置而变化。当你为自己的项目记录地址时，注明哪些部分固定、哪些部分可变，有助于与只需要域名或需要指向特定章节完整URL的协作者清晰沟通。
为假设项目制作一张地址说明卡
记录一张简短的说明卡，对应项目中每一个重要地址。对于我们这个假设的阅读笔记站点，说明卡可以包含四行。第一行写明用途：以紧凑显示模式分享某一页阅读笔记。第二行原样记录完整地址：https://example.org/notes/first-page?view=compact#intro。第三行列出各部分：方案 https，域名 example.org，路径 /notes/first-page，查询 view=compact，片段 intro。第四行备注上下文，例如注明这是一个用于学习的假设示例。
把说明卡保存在你实际会回顾的格式中。项目文件夹里的纯文本文件、笔记工具中的一条记录、或表格里的一行都可以。格式本身不如把拆解结果写在原始字符串旁边这个习惯重要。日后需要向协作者解释地址或排查链接问题时，旁边就有标注好的各部分，省去重新从头分析的时间。
如果项目有多个值得分享的页面，就为每个地址做一张卡。随着时间推移，这些卡片会形成一个小型参考集，展示项目实际使用了哪些路径、出现了哪些查询参数、是否定义了片段。这是一种文档习惯而非技术要求，但它往往能在多人协作同一站点时减少混淆。
用手工复制与逐项标记核对说明卡
检查说明卡与原始字符串是否一致，方法是把地址逐字符复制到一行空白处，然后标出每个边界。从左开始：:// 之前的所有内容都是方案。在 :// 与域名后面第一个斜杠之间是权限部分，在我们的例子中就是 example.org，没有显示端口号。从那个第一个斜杠到问号之间是路径。问号与井号之间是查询。井号之后是片段。
标注时如果在可视化编辑器中工作，可以为每个片段使用不同颜色或高亮。这样不匹配之处一眼就能看出。例如，如果你不小心把问号包含在了路径里，或者忘记片段是从井号之后开始而不包含井号本身，颜色边界看起来就会不对。这是一种简单的校对技巧，不是正式的验证工具，但能抓住最常见的转录错误。
把标注出的各部分与说明卡上记录的定义做对比。如果卡上写的查询是 view=compact，但你高亮的片段显示的是 view=compact&sort=date，那么其中必有一处有误。在把地址分享给其他人之前先解决这个差异。这种手工核对只需一分钟，却能防止那种让协作者到达错误页面或书签失效的小错误。
保留说明记录供日后使用
把完成的说明卡存放在项目演进时你能再次找到的位置。如果之后添加了新页面，你可以复制卡片格式并填入新的路径、查询和片段，无需重新推导结构。如果协作者询问某个地址的含义，你可以直接指向说明卡，而不必凭记忆解释。
在撰写文档、起草链接到站点的社交媒体帖子或设置重定向时，说明卡同样有用。在这些场景中你需要知道地址的哪一部分是稳定的、哪一部分可能变化。域名一旦选定很少更改，但路径和查询可能随着内容重组而变动。有了书面记录，这些决策就变得可见而非隐含。
在哪里、以何种方式保存这些记录完全由你决定。有人偏好在代码仓库中放一个专门的 markdown 文件，有人在站点文件旁边保留一个简单的文本文档。关键在于拆解结果以可检索的形式存在，这样下次你或其他人需要理解地址时，分析工作已经完成了。
常见问题
域名和URL是同一个东西吗？
不是。域名标识的是你想访问的服务器，而URL是完整地址，还包含协议、路径以及可选的查询和片段。域名只是完整URL中的一个组成部分。12
井号后面的片段部分会发送给服务器吗？
不会。片段标识符即井号之后的部分，不会随请求一起发送给服务器。它由浏览器使用，用于在已获取的资源中滚动到书签位置。2
URL中需要写上端口号吗？
通常不需要。当网络服务器使用HTTP协议的标准端口时端口号一般省略，HTTP是80，HTTPS是443。只有在服务器使用非标准端口时才需要显式写出。2