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

当你第一次准备搭建网站时，浏览器地址栏里的那串字符看起来可能像一整块没有区分的符号。把它拆解成有名称的各个部分，能帮助你准确地向合作者描述你的站点、核对自己的工作，并避免把选择的域名和页面实际使用的完整地址混为一谈。

域名与完整URL分别回答什么问题

假设你正在规划一个小型个人项目，并在纸上草拟了一个地址：https://example.org/notes/first-page?view=compact#intro。这个地址纯属假设，仅用于拆解字符串结构，并不指向真实页面或已上线的服务器。观察它就能发现，这串字符所做的事情远不止为网络上的某一台机器命名。

域名回答的问题是「我在和哪台服务器或主机通信？」域名是互联网基础设施的关键组成部分，因为它们为互联网上任何可用的网络服务器提供了人类可读的地址，取代了计算机容易处理但人们难以记住的数字IP地址。在我们的例子中，域名部分是example.org。仅凭这一部分就能标识主机，而不涉及该主机上的任何特定页面、文件或显示偏好。¹²

完整URL回答的是一个更细致的问题：「在那台主机上，哪个具体资源、在什么条件下、从哪个位置开始？」URL是互联网上唯一资源的地址，也是浏览器用来获取已发布资源（如HTML页面、CSS文档和图片）的关键机制之一。我们例子中的完整字符串不仅包含主机，还包含路径、查询和片段，每一层都增加了域名本身不携带的额外具体信息。³

在示例地址中标出各个部分

把示例字符串写在一行空白处，然后标记出每个边界。第一段是https，即方案，它指明浏览器请求资源时必须使用的协议。分隔符://紧跟在方案之后，引出权威部分。在本例中，权威部分只包含域名example.org，没有显式端口号，这意味着使用默认的HTTPS端口。³

权威部分之后是路径/notes/first-page。路径标识的是服务器上被请求的具体资源。一个问号随后引出查询字符串view=compact。查询参数是提供给网络服务器的额外键值对，问号正是标示该部分开始的字符。最后，一个井号引出片段intro。片段相当于资源内部的一个书签，为浏览器指明应显示该书签位置的内容。值得注意的是，片段标识符不会随请求发送给服务器。³

总结各边界的位置：方案在双斜杠前的冒号处结束；域名在权威部分之后的第一个单斜杠处结束；路径在问号处结束；查询在井号处结束；片段从井号一直延伸到字符串末尾。每个分隔符都充当明确且无歧义的分界，因此你可以按顺序扫描这些字符来定位每一个部分。³

相同主机、不同路径与查询

保持主机部分example.org不变，只改变路径。比较https://example.org/notes/first-page与https://example.org/notes/second-page。域名和方案完全相同，但路径的最后一段不同。这两个字符串指向同一台主机上的不同资源。你仅凭字符串文本就能观察到这一点，无需加载任何一个页面或了解服务器的配置方式。

现在保持路径不变，只改变查询。比较https://example.org/notes/first-page?view=compact与https://example.org/notes/first-page?view=full。两个字符串的路径相同，因此都引用同一个资源位置。查询不同，意味着服务器可能收到关于如何呈现该资源的不同指令。服务器实际上是否使用view参数、忽略它还是以其他方式处理未知参数，这是关于服务器行为的问题，URL字符串本身无法回答。

最后，只改变片段。比较https://example.org/notes/first-page?view=compact#intro与https://example.org/notes/first-page?view=compact#summary。井号之前的所有内容完全相同。由于片段不会发送给服务器，这两个字符串从浏览器到服务器产生的是相同的请求。差异只影响资源加载后浏览器滚动或定位显示的位置。当你需要判断两个地址是否共享同一个链接目标、还是仅在页面内的起始位置不同时，这个区分很有用。

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

记录你的假设项目的目的，用一句话概括即可。在本练习中，可以写类似这样的内容：一个个人笔记页面，以紧凑阅读视图显示，并从引言部分开始。这句话捕捉了地址背后的意图，也为后续检查字符串是否与计划一致提供了参照。

在目的句下方，把完整地址的每个部分单独列一行并标注名称。写下方案，注明它指定了安全连接。写下域名，注明它标识主机。写下路径，注明它指向笔记栏目中的一个具体页面。写下查询，注明它请求紧凑显示模式。写下片段，注明它标记引言为起始滚动位置。这份清单就是你的地址说明卡。

说明卡不需要很复杂。一个纯文本文件、项目笔记里的一条记录，甚至显示器旁边的一张便签都可以。价值在于把拆解结果集中写在一个地方，这样你或合作者就能直接查阅，而不必凭记忆重新推导每个部分。如果项目将来使用多个地址，可以为每个地址各做一张卡片并放在一起。

手工核对说明卡

手工核对能发现拼写错误和边界标注错误，这些在一瞥字符串时很容易忽略。以下步骤是基于直接复制与标记方法的作者建议，不来自任何外部规范或工具要求。

如果某个标签与你在卡片上写的内容不一致，修正卡片而不是原始地址字符串，然后重新检查。这样做能保持参考记录的准确性，同时不改动你打算使用的地址。

检查卡片上的片段标签是否与复制字符串中最后一个井号之后的文字一致。如果你的地址中没有井号，明确写上「无片段」，这样将来的阅读者就知道这个缺失是有意的而不是遗漏。

步骤 1

把完整地址字符串按你打算使用的样子原样复制，粘贴到一行新的空白文本中。不要凭记忆重新输入。

步骤 2

按顺序划出或高亮每个分隔符：方案之后的冒号加双斜杠、开始路径的第一个单斜杠、问号以及井号。

步骤 3

把每个部分的标签直接写在复制字符串的上方或下方，逐项与说明卡上的内容对照。

步骤 4

把卡片上的每个标签与刚标记的段落逐一比较，确认方案、域名、路径、查询和片段在拼写和边界位置上都一致。

保留记录供以后使用

把完成的说明卡和其他项目规划文档放在一起。如果之后要写文档、把地址分享给合作者，或者排查一个看起来不对的链接，说明卡能给你现成的拆解结果。你可以指出具体是哪个部分发生了变化，而不是粘贴整串字符让别人自己去找出不同。

你可能会发现，自己对说明卡应该多详细的偏好在不断变化。有人只记录域名和路径，有人则把每个查询参数和片段都包含进去。两种选择都没有错。重要的是，你记录的详细程度要与你以后重新查看地址时所需的详细程度匹配。如果项目增长到包含多个带有不同查询参数的页面，更详细的卡片能帮你省去逆向推导差异的麻烦。

这种做法在把项目交给别人时同样有帮助。新的合作者可以阅读说明卡，理解地址的哪个部分控制主机、哪个部分控制页面、哪个部分控制显示偏好，而不需要先查阅外部资料。在上线之前养成标注地址各部分的习惯，能建立一份小而持久的项目文档，维护成本几乎为零。

常见问题

改变URL中的片段会产生不同的页面吗？

不会。片段不会发送给服务器，因此只改变片段并不会请求不同的资源。它只告诉浏览器在同一个页面加载后滚动或定位到哪个位置。³

仅凭URL字符串能判断服务器是否会使用查询参数吗？

不能。URL字符串显示了请求中包含哪些参数，但服务器是使用、忽略还是以其他方式处理这些参数，取决于服务器自身的配置。字符串本身无法确认服务器行为。

域名和完整URL是同一个东西吗？

不是。域名标识主机，而完整URL在域名的基础上还加上了方案，并可能包含路径、查询和片段，以指向该主机上的一个具体资源。域名是更大URL字符串中的一个组成部分。¹³