域名与URL的区别：首次建站时怎样理解网站地址

准备第一个网站时，你会遇到两个紧密相关的概念：域名和URL。它们在日常对话中看起来相似，但各自回答的是关于访问者如何找到你内容的不同问题。本文用一个假设地址来展示每个部分的含义，并说明如何保留一份实用的记录。

一个用于阅读练习的假设地址

假设你正在规划一个小型个人项目，并为其中一个页面草拟了一个示例地址。你写下的地址是 https://example.org/notes/first-page?view=compact#intro。这个字符串纯属假设，仅用于练习阅读网址的各个部分，不表示该页面真实存在或已经发布。将它当作练习字符串，可以让你专注于结构本身，而不必担心一个真实站点的细节。

这个字符串中的域名部分回答的问题是「我在找哪台服务器」。域名是互联网基础设施的关键组成部分，它为互联网上任何可用的网络服务器提供了一个人类可读的地址。计算机之间通过IP地址相互通信，而IP地址是一长串数字，人们很难记住，而且可能随时间变化。像 example.org 这样的域名解决了这个问题，它给服务器赋予了一个人类能够阅读和记忆的标签。¹

完整的URL回答的是一个更具体的问题：「我想要那台服务器上的哪个资源」。URL是统一资源定位符的缩写，它是互联网上某个唯一资源的地址，也是浏览器用来获取已发布资源的关键机制之一，这些资源包括HTML页面、图片、样式表等。域名指向的是服务器整体，而URL的其余部分则将请求缩小到该服务器上的某个特定页面或文件。²

逐段标出示例地址的各个部分

示例字符串的第一部分是 https，即方案。方案指示浏览器在请求资源时必须使用的协议。对于网站来说，协议通常是HTTPS或其未加密版本HTTP。在我们的示例中，https 告诉浏览器在联系服务器时使用安全版本的协议。²

在方案和分隔符 :// 之后，下一部分是 example.org。这是域名，它标识了被请求的是哪台网络服务器。域名的结构由若干个以点号分隔的部分组成，从右向左阅读。最右边的部分，这里是 .org，是顶级域，它告诉用户该域名背后服务的一般用途。它左边的标签 example 是为这台服务器选定的具体名称。¹

域名之后的所有内容分别是路径、查询和片段。路径 /notes/first-page 指向服务器上的一个特定资源。问号引导查询字符串，在本例中是 view=compact；查询是提供给网络服务器的额外参数，以键值对的形式出现。井号引导片段，这里是 intro，它充当资源内部的一个书签，并且不会随请求一起发送给服务器。因此，问号标志着查询的开始，井号标志着片段的开始。²

保持主机不变，对比不同的路径和查询

现在保持示例的主机部分不变，只改变其他部分。如果你把路径 /notes/first-page 替换为 /notes/second-page，域名 example.org 和方案 https 完全不变。变化的是地址所指向的资源位置。主机仍然标识同一台服务器，但路径现在把浏览器引导到该服务器上的另一个位置。仅凭阅读字符串就能看出这一点，你不需要访问页面或了解服务器的配置方式。

接下来，只改变查询部分。把 view=compact 替换为 view=full，同时保持路径为 /notes/first-page。字符串现在读作 https://example.org/notes/first-page?view=full#intro。资源的位置没有移动，但问号之后携带的额外参数不同了。这个观察针对的是字符串本身的结构，它并不告诉你任何特定服务器会如何处理这些参数，因为每台网络服务器对参数都有自己的处理规则。

最后，去掉片段。地址变为 https://example.org/notes/first-page?view=compact，末尾不再有 #intro。被请求的资源与之前相同，片段只是给浏览器提供了在该资源内部跳转到某个书签位置的指引。去掉片段意味着浏览器将从资源的默认起始位置加载，而不是滚动到某个特定区域。将这三种变体并排对比可以看出，主机、路径、查询和片段各自携带独立的信息，改变其中一个并不会自动改变其他部分。

为假设项目制作一张地址说明卡

为你打算在项目中使用的地址写一张简短的说明卡。这张卡不需要遵循正式模板，在笔记本或纯文本文件里写几行就够了。记录三件事：用你自己的话写明这个地址的用途、你打算分享的完整URL、以及每个部分的标注清单。这是本文建议的个人整理习惯，不是任何规范的要求。

对于这个假设示例，用途可以写成「项目中第一条笔记的紧凑视图」。完整地址是 https://example.org/notes/first-page?view=compact#intro。在下方，把每个部分单独列一行：方案是 https，域名是 example.org，路径是 /notes/first-page，查询是 view=compact，片段是 intro。把这些分开写出来，之后就容易发现遗漏或拼错的部分。

说明卡的真正价值在你回顾它时才会显现。如果你无法解释某个部分为什么存在，那就是一个信号，提示你重新考虑它是否应该在那里。例如，如果你添加了一个查询参数却不确定它控制什么，可以先把它移除，等到理解其作用后再加回来。说明卡把一长串字符变成了一组小的、可逐项检查的决定。

手工核对说明卡

说明卡写好后，仅用复制粘贴和文本编辑器就能对它进行核对。目标是确认你列出的每个部分都与实际地址逐字一致。以下步骤是作者建议的仔细手工检查方法。

核对过程中要注意各部分之间的边界字符。冒号加两个斜杠将方案与域名分隔开。域名之后的第一个单斜杠开始路径。问号将路径与查询分隔，井号将查询与片段分隔。如果你复制的地址中这些边界字符有缺失或位置错误，它就不会按照说明卡上的描述工作。

如果发现不一致，修正说明卡或地址后重新检查。路径中的一个错误字符或查询前缺少一个问号，都可能改变整个字符串的含义。重复两到三次这个过程，可以在你把地址分享给协作者或嵌入其他文档之前，建立起对说明卡准确性的信心。

步骤 1

将说明卡上的完整URL复制并粘贴到一个纯文本编辑器中。用高亮或方括号标出每个边界：方案后面的 ://、域名后面的第一个 /、查询前面的 ?、以及片段前面的 #。

步骤 2

逐项阅读说明卡上标注的每个部分，并与粘贴字符串中的对应片段进行比较。检查方案的拼写、域名的各个标签、路径中的每一个斜杠、查询的键和值、以及片段名称。记下你发现的任何差异。

保留这份记录供以后使用

把完成的说明卡存放在你保存项目笔记的地方。它可以和站点大纲一起放在一个文本文件里，也可以放在与协作者共享的文档中，甚至可以写在配置文件顶部的注释里。格式不如习惯重要——在地址上线之前把它写下来才是关键。当你需要向别人解释这个地址，或者隔了一段时间再回来看它时，说明卡能给你一个快速参考，而不必从头重新解析字符串。

随着项目增长，你可能会为其他页面创建更多的说明卡。每一张都遵循相同的模式：用途、完整地址、标注清单。随着时间推移，这组卡片会成为你站点地址结构的一张小地图。你可以浏览这些卡片来发现规律，比如路径层级是否过深、查询参数是否有重叠，然后决定是否简化它们。

这个做法在你撰写文档、在邮件中分享链接或日后设置重定向时同样有帮助。因为每张卡片已经把地址拆分成命名的部分，当某个页面移动时你可以迅速识别出哪个部分发生了变化。你不需要为创建过的每个地址都保留说明卡，选择哪些地址值得记录由你自己决定。重点在于这个习惯存在，并且在某个地址重要到值得仔细记录时随时可用。

常见问题

示例地址 https://example.org/notes/first-page?view=compact#intro 是一个真实页面吗？

不是。这个地址在本文中仅作为一个假设字符串使用，用于练习如何阅读URL的各个部分。文中不声称该页面存在或已经发布。

URL中的查询和片段有什么区别？

查询跟在问号后面，由键值对组成，作为额外参数发送给网络服务器。片段跟在井号后面，充当资源内部的书签，它不会随请求一起发送给服务器。²

我需要为网站上的每个页面都写一张说明卡吗？

不需要。说明卡是一种个人整理建议。你可以只为主页或关键着陆页这样重要的地址创建说明卡，对不太关键的路径则省略。