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

网站上线前，你会遇到两个紧密相关但不同的概念：域名和完整URL。了解它们各自告诉你什么信息，有助于你准确描述网站、核对自己的工作，并在分享链接时避免混淆。本文通过一个假设地址逐步拆解，让你看清各部分如何组合在一起。

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

假设你正在筹备一个小型个人项目网站，想弄清楚将来分享给读者的地址到底由什么组成。为了这次练习，我们使用一个假设地址：https://example.org/notes/first-page?view=compact#intro 。这个地址纯粹用于拆解字符串结构，不代表任何真实存在或已上线的页面。从一个具体的字符串出发，更容易看清哪一部分回答了哪一个问题。

域名回答的是「我要访问哪台服务器」这个问题。域名是互联网基础设施的关键部分，它为互联网上任何可用的网络服务器提供了人类可读的地址。计算机通过IP地址定位服务器，而IP地址是纯数字的，人们很难记住，域名正是为了解决这个可读性问题而存在的。在我们的例子中，example.org就是域名，它告诉你处理请求的服务器身份，但不包含比这更具体的信息。¹

完整URL回答的是一个更窄的问题：「我要请求那台服务器上的哪个具体资源」。URL是互联网上唯一资源的地址，也是浏览器用来获取已发布资源的关键机制之一，这些资源包括HTML页面、CSS文档和图片等。如果域名指向一栋建筑，那么URL指向的是建筑里某个具体的房间、书架，甚至书架上某本书中的特定段落。这个区别很重要，因为两个人可能分享同一个域名，却想把访客引向完全不同的页面。²

标出本例地址中的各个组成部分

把完整的示例字符串单独写在一行上，方便你逐段标记：https://example.org/notes/first-page?view=compact#intro 。第一个片段https是协议方案。协议方案告诉浏览器必须使用哪种协议来请求资源。对于网站来说，协议通常是HTTPS或HTTP。在我们的例子中，https告诉浏览器在与服务器通信时使用安全连接。²

下一个片段example.org是位于授权部分内的域名。授权部分通过字符组合://与协议方案分隔，它指明被请求的是哪台网络服务器。域名之后是路径：/notes/first-page 。路径表示资源在网络服务器上的位置，你可以把它想象成域名所标识的建筑内的街道地址。路径始终以正斜杠开头，并用额外的斜杠来分隔不同层级。²

问号?引出查询部分。问号与下一个分隔符之间的所有内容都属于查询字符串。在我们的例子中，view=compact就是查询。查询参数是提供给网络服务器的额外键值对，服务器可以利用它们在返回资源之前做额外处理。井号#引出片段，也叫锚点。在我们的例子中，intro就是片段。锚点代表资源内部的一个书签，它给浏览器指明应显示该书签位置的内容。记住一条实用规则：问号永远引导查询，井号永远引导片段。²

保持主机不变，对比不同路径和查询字符串

保持示例中的协议方案和域名不变，只替换路径。将https://example.org/notes/first-page?view=compact#intro 与https://example.org/gallery/thumbnails?view=compact#intro 做对比。域名部分完全相同，所以两个地址指向同一台服务器。不同的是路径：/notes/first-page 与 /gallery/thumbnails 。这说明两个URL指向同一主机上的不同资源，尽管域名后面第一个斜杠之前的字符串完全一样。

现在只改变查询字符串，路径保持不变。将https://example.org/notes/first-page?view=compact#intro 与https://example.org/notes/first-page?view=full#intro 做对比。路径相同，所以请求的底层资源是同一个页面。查询不同：view=compact 与 view=full 。这意味着服务器收到了一条以不同方式呈现同一资源的指令。你并不是在断言某台特定服务器会如何实际响应，你只是在观察字符串携带了不同的指令。

最后，只改变片段。将https://example.org/notes/first-page?view=compact#intro 与https://example.org/notes/first-page?view=compact#summary 做对比。域名、路径和查询全部相同，只有片段从intro变成了summary。这告诉浏览器滚动到同一文档中另一个书签的位置。片段标识符不会随请求发送给服务器，因此改变片段不会改变服务器返回的内容，它只改变浏览器在屏幕上显示内容的位置。

为你的项目制作一张地址说明卡

记录地址的用途时，先用一句平实的话写清楚，然后再写其他内容。对于我们这个假设项目，你可以写：「这是我的笔记合集主阅读页，以紧凑布局展示，滚动到引言部分。」先说明用途，能给你一个参照点，用来检查URL的每个部分是否真的符合你的意图。

接下来，把你计划分享的完整地址单独写在一行上。在那行下方，列出每个部分并附上简短标签：协议方案、域名、路径、查询、片段。对于我们这个例子，说明卡的内容是：协议方案为https，域名为example.org，路径为/notes/first-page，查询为view=compact，片段为intro。把五个项目分别写在独立行上，能让你一眼发现遗漏的斜杠、拼错的参数名，或者与文档中标题不再匹配的片段。

每次制作说明卡时使用一致的格式，这样将来的条目可以一目了然地相互比较。你可以选择始终按URL字符串中出现的顺序列出各部分，也可以按功能分组。两种做法都行，只要你坚持一致使用。说明卡是你个人的参考工具，不是正式规范，所以优先级是让自己看得清楚，而不是遵循某个外部标准。

通过手工复制与逐项标记核对说明卡

检查说明卡与原始地址字符串是否一致，方法是把完整URL复制到一个纯文本编辑器中，然后在每个分隔符前插入换行。在://之后、即协议方案与授权部分的分界处换行；在域名结束、路径第一个正斜杠开始处换行；在问号前换行；在井号前换行。这样你就得到五个可见片段，可以逐一与说明卡上的条目做比较。

把每个部分的预期值写在对应片段的下方单独一行，然后逐行对照阅读。如果URL中的片段显示example.org，你的说明卡上也写着example.org，那这一项就核对通过。如果发现不匹配，就修正说明卡或地址中有错误的那一方。这种手工比较能捕捉到只凭一眼扫过浏览器地址栏中的长字符串时很容易忽略的拼写错误。

每次修改地址后都重复这个核对步骤。即使是很小的改动，比如添加第二个查询参数或重命名一个片段标识符，也可能引入多余字符。把核对变成习惯，意味着你能在问题还容易修复时就发现它，而不是等到已经把链接分享给协作者或嵌入到其他文档中之后才察觉。

保留这份记录供以后写作和沟通使用

把地址说明卡存放在你撰写新内容或向他人解释网站结构时能快速找到的地方。一个简单的文本文件、项目管理工具中的一条笔记，甚至配置文件顶部的注释都可以。格式本身不太重要，重要的是每次地址发生变化时都保持更新。

当你把地址分享给协作者时，考虑把说明卡和原始URL一起附上。说明卡告诉他们每个部分应该做什么，这能减少来回提问，比如「查询参数控制的是布局还是内容」。你提供的是上下文信息，而不是规定他们必须如何解读URL，但这些额外的标注通常能为所有相关人员节省时间。

自行决定你的记录需要详细到什么程度。有些项目负责人为网站公开的每个URL都维护一张说明卡，另一些人只记录最常分享的那几个地址。两种做法都没有对错之分。关键在于，当你确实记录一个地址时，记录是准确的，反映的是URL的当前状态，而不是你后来已经修改过的旧版本。

常见问题

修改URL中的片段标识是否会改变服务器返回的内容？

不会。片段是井号后面的部分，它不会随请求发送给服务器。片段只告诉浏览器在已加载的资源中滚动到哪个位置。改变片段会改变访客在屏幕上看到的内容，但不会改变服务器的响应。²

两个不同的URL能否共享同一个域名？

可以。域名标识的是服务器，而路径、查询和片段指定的是该服务器上被请求的具体资源。同一个域名下可以有任意数量的不同URL，分别指向不同的资源。²

在浏览器中输入URL时是否必须写协议方案？

实际使用中，如果你省略了协议方案，浏览器会自动补上，默认使用HTTP。不过，当你为项目记录或文档化一个URL时，明确写上协议方案能避免歧义，让地址保持完整。²