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

第一次准备网站时，浏览器地址栏里那串字符并不只是一个你挑好的名字。理解每个部分的作用，能帮助你规划内容、准确分享链接，并在日后排查问题时快速定位。

一个用于拆解阅读的假设地址

假设你正在规划一个小型个人项目，在纸上写下了 https://example.org/notes/first-page?view=compact#intro 这个地址。这个地址纯属假设，我们并不声称该页面真实存在或已上线，它只是用来拆解字符串各部分如何组合的练习素材。其中 example.org 是域名部分，它用人类可读的名称标识一台网络服务器。域名之所以存在，是因为互联网上的计算机通过数字形式的IP地址来寻址，而这些数字对人来说很难记忆，域名就是这些数字的可读替代。¹

然而，完整的字符串是一个URL。URL是互联网上唯一资源的地址，也是浏览器用来获取已发布资源（如HTML页面、图片或样式表）的关键机制之一。域名回答的是「该联系哪台服务器」这个问题，而完整的URL回答的是「我要那台服务器上的哪个具体资源，在什么条件下获取」。这个区分是本文后续所有内容的起点。²

在接下来的各节中，请始终记住这同一个示例。下面的每一个观察都指向同一串字符，你可以用笔或文本编辑器跟着逐项验证。

在示例中标出每个组成部分

标注地址 https://example.org/notes/first-page?view=compact#intro 的各段。开头的 https 是协议方案，它告诉浏览器请求资源时应使用哪种协议；对于网站来说通常是HTTPS或其未加密版本HTTP。紧跟在分隔符 :// 之后的部分是权限段，其中包含域名 example.org，指明要请求的是哪台网络服务器。在许多URL中这里还可以出现端口号，但当服务器使用HTTPS的标准端口时通常省略。²

权限段之后是路径 /notes/first-page。路径指向网络服务器上的一个资源。在早期，路径代表服务器上的物理文件位置，而现在它大多是服务器处理的一种抽象，并不对应真实的物理文件。路径之后，问号 ? 引出查询字符串 view=compact。查询参数是提供给网络服务器的额外键值对，服务器可以利用它们在返回资源之前做额外处理。每台服务器对参数有自己的规则。²

最后，井号 # 引出片段标识符 intro。锚点相当于资源内部的一个书签，为浏览器指示应显示该书签位置处的内容。值得注意的是，井号之后的部分（即片段标识符）永远不会随请求发送到服务器。因此在我们的示例中，问号标记查询的开始，井号标记片段的开始；两者之间属于查询，井号之后属于片段。²

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

现在保持主机部分 example.org 不变，设想两个替代地址。第一个是 https://example.org/notes/second-page?view=full，第二个是 https://example.org/gallery/thumbnails?sort=date。在这两种情况下，协议方案和域名与原示例完全相同，变化的是路径和查询字符串。第一个替代地址的路径指向同一 notes 目录下的不同资源，第二个则转向一个名为 gallery 的完全不同目录。查询参数也不同：view=full 对比 sort=date。这些都是纯粹的字符串层面观察，我们并不推断任何特定服务器会如何处理它们。

这个对比说明，仅凭域名无法判断某人指的是哪个页面或资源。两个人可能共享同一个域名，却在谈论完全不同的内容，因为路径和查询携带了那些额外信息。当你记录或分享一个地址时，包含完整路径和所有查询参数能确保接收者找到你原本想指向的资源。

片段的行为与路径和查询不同。如果你把片段从 #intro 改为 #summary 而保持其余部分不变，浏览器仍然会向服务器请求相同的资源，只是会滚动到资源内部另一个书签位置。由于片段永远不会发送到服务器，两个仅在片段上不同的URL指向的是同一个服务器端资源。在决定说明卡中应包含哪些部分时，这是一个有用的区分。²

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

记录以下信息到一张卡片或纯文本文件中，作为你假设项目的地址说明。先写一句简短的目的陈述，例如：「我的阅读笔记第一页的地址，以紧凑视图显示，滚动到引言部分。」然后在单独一行写出完整地址 https://example.org/notes/first-page?view=compact#intro，方便复制时不会意外改动。

在完整地址下方，逐项列出每个部分及其标签。协议方案：https。域名：example.org。路径：/notes/first-page。查询：view=compact。片段：intro。把它们分别写出来，能迫使你注意每个边界字符的位置。域名后面的斜杠开始路径，问号开始查询，井号开始片段。如果这些边界字符缺失或放错位置，地址的含义就不同了。

你还可以加一条简短备注，说明你认为分享时哪些部分是必要的。在这个假设案例中，协议方案、域名和路径是到达资源所必需的。查询参数 view=compact 影响资源的呈现方式，如果你希望接收者看到相同的展示效果，可以包含它。片段 #intro 只影响页面内的滚动位置，在简短引用中可以省略而不改变加载的资源。这些是你根据自身沟通需要做出的选择，不是任何规范强加的规则。

手工核对说明卡

在将说明卡用于任何实际沟通之前，逐字符对照原始字符串进行检查。以下步骤是作者建议的简单人工审查方法，不需要任何特殊工具。

这个过程只需一两分钟，但能捕捉最常见的错误：缺少斜杠、问号放在查询之后而不是之前、或者片段标识符被误写进了路径栏。

如果发现不一致，立即修正说明卡并重新通读一遍完整地址。现在养成快速核验的习惯，日后与合作者分享地址或粘贴到文档中时就能避免混淆。

步骤 1

将说明卡上的完整地址复制到一行空白文本中，再将原始地址 https://example.org/notes/first-page?view=compact#intro 复制到紧接其下的一行。从左到右逐字符比较两行，注意冒号、斜杠、问号、等号和井号的位置。

步骤 2

检查说明卡上每个标注部分是否与完整地址中对应片段一致。确认协议方案栏写的是 https 而非其他内容，域名栏写的是 example.org 且前后没有多余斜杠，路径栏以斜杠开头且内容为 /notes/first-page，查询栏写的是 view=compact 而不含问号，片段栏写的是 intro 而不含井号。

步骤 3

记录本次核对的日期，并注明你做了哪些修正。如果之后为项目更改了地址，更新说明卡并重复比较，使说明卡始终反映当前版本。

保留记录供日后使用

将地址说明卡存放在你日后写文档、与合作者分享链接或中断后重新回到项目时能找到的地方。项目文件夹中的一个纯文本文件就很合适，因为它便于搜索且不依赖任何特定应用。目标不是建立一套复杂系统；一个你真正会打开的简短文件，比一个从未填写的复杂模板更有用。

当你最终为项目添加更多页面时，可以沿用同样的格式。给每个地址单独建一张卡片或在列表中添加新条目，始终记录目的、完整地址和各部分标签。随着时间推移，这组记录会成为快速参考，省去你重新阅读长字符串并猜测各部分边界在哪里的麻烦。

你选择记录哪些内容是个人的决定。有些人偏好记录每个片段，因为他们想要精确的滚动位置；另一些人省略片段，因为他们认为那是临时的。两种方式都没有错。重要的是你的记录足够一致，使你日后能信任它，并且你能向另一个人解释地址的哪些部分是必要的、哪些是可选的。这种清晰度就是在网站上线前花几分钟标注一个假设字符串所带来的实际回报。

常见问题

在示例地址中，片段 #intro 会被发送到服务器吗？

不会。片段标识符永远不会随请求发送到服务器，它只告诉浏览器在已加载的资源内滚动或跳转到哪个位置。²

如果只把查询参数从 view=compact 改为 view=full，请求的是不同资源吗？

路径和域名保持不变，所以你向服务器请求的基础资源是相同的。不过服务器可能利用不同的参数来改变资源的呈现方式，具体行为取决于服务器的配置。²

分享地址时需要包含协议方案 https 吗？

在大多数浏览器中，只输入域名而不写协议方案时会自动使用HTTP或HTTPS。不过在说明卡中写明完整的协议方案可以消除歧义，确保别人将地址复制到不会自动补充协议的环境中时仍然完整可用。