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

在准备上线一个网站之前，你会同时接触域名和完整URL这两个概念。它们有重叠之处，但回答的是不同的问题；混淆两者会在分享链接或配置设置时带来困扰。本文用一个假设地址逐段拆解，帮助你看清每一部分的含义。

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

域名是为互联网上可供访问的服务器提供的人类可读地址。计算机之间通过IP地址互相通信，但那些数字串对人来说难以记忆，而且可能随时间变化。域名用字母、数字和连字符以点分隔的方式，为每台服务器赋予一个便于记忆的标签，解决了这个问题。¹

URL则更进一步。它是互联网上某个唯一资源的地址，不仅告诉浏览器该联系哪台服务器，还指明要从该服务器获取哪一份具体资源。理论上每个有效的URL都指向一个唯一资源。域名是URL内部的一个组成部分，但完整URL还包含协议方案，并且可能包含路径、参数和片段。²

本文使用一个假设地址来练习逐段阅读：https://example.org/notes/first-page?view=compact#intro —— 这个字符串纯粹为了拆解练习而编造，不指向真实页面，也没有服务器会对它作出响应。目标只是辨认字符串中每一段代表什么，以便你把同样的阅读方法应用到自己的项目地址上。

在本例中标出各部分

把完整字符串 https://example.org/notes/first-page?view=compact#intro 单独写在一行上，标出各部分之间的边界。协议方案是https，出现在 :// 分隔符之前，表示浏览器请求资源时必须使用的协议。权威部分紧跟分隔符之后，在本例中由域名 example.org 构成。路径是 /notes/first-page，位于域名之后，标识该服务器上某个具体资源的位置。²

问号引导查询部分。在本例中查询是 view=compact，即一个键值对，向服务器提供额外参数。井号引导片段部分。本例中片段是 intro，它相当于资源内部的一个书签，并且不会随请求发送到服务器。记住这两个定界符——问号对应查询、井号对应片段——就能解析你遇到的任何URL。²

注意域名 example.org 本身也有内部结构。最后一个组成部分 org 是顶级域，example 是位于其前的标签。它们共同构成浏览器用来定位正确服务器的主机部分。顶级域是域名中最通用的部分，通常能提示该站点的用途或类别。³¹

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

现在保持主机部分 example.org 不变，只修改路径。如果地址变成 https://example.org/notes/second-page?view=compact#intro，浏览器仍然联系同一台服务器，但路径段从 /notes/first-page 变成了 /notes/second-page。字符串的差异仅限于路径；前后其余部分完全相同。这说明路径是URL中区分同一主机上不同资源的部分。

接下来保持路径不变，只修改查询。如果地址写成 https://example.org/notes/first-page?view=full#intro，路径仍然是 /notes/first-page，但查询从 view=compact 变成了 view=full。当存在多个键值对时，查询字符串用 & 符号分隔各对。本例只有一个键值对，所以不出现 & 符号。查询提供服务器在返回资源之前可以使用的额外参数，不过每台服务器对参数的处理规则各不相同。²

最后去掉片段：https://example.org/notes/first-page?view=compact —— 字符串变短了，但协议方案、主机、路径和查询都没有改变。片段只影响浏览器在返回的文档中滚动到哪个位置，不改变请求的是哪份资源。观察这些细微的字符串差异，能帮助你在链接失效或需要更新内容中的地址时准确描述变化所在。

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

记录以下信息到一张卡片或笔记中，用于你打算使用的任何地址。先用一句简短的话写明页面目的，例如：“该页面以紧凑列表形式展示项目笔记。”然后原样写出完整地址：https://example.org/notes/first-page?view=compact#intro。在下方逐行列出每个已标注的部分：协议方案、主机、路径、查询和片段。这张卡片在你需要向协作者解释地址或检查链接是否符合意图时就是参考依据。

这个练习的价值不在于具体示例本身，而在于养成使用前先把地址拆分为命名组件的习惯。日后你为自己的站点创建真实页面时，可以重复同样的卡片格式。如果你的项目在 /notes/ 下有笔记区、在 /gallery/ 下有图库区，每个页面各有一张卡片，主机相同而路径不同。查询和片段是否出现取决于页面需要。

卡片上的用语保持简洁明了。避免使用只有你自己半年后才能理解的缩写。如果你想为某个查询参数写一句简短的存在理由，也用同样简洁的风格来写。卡片是沟通工具而非技术规格说明，清晰比完整更重要。

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

检查你的说明卡，方法是把完整URL从卡片复制到纯文本编辑器中，然后直接在文本里标注每一段。在每个边界处加注释或括号：标出协议方案在哪里结束、主机在哪里结束、路径从哪里开始到哪里结束、问号在哪里引导查询、井号在哪里引导片段。如果任何边界不清楚或卡片上缺少某一段，先更新卡片再继续。

逐字符进行第二遍核对，检查拼写和标点。主机与路径之间缺少一个斜杠，或查询中多出一个问号，都会产生与你意图不同的字符串。因为本例是假设的，你并非在测试服务器是否响应；你只是在确认卡片上的字符串与你标注的字符串一致。这个习惯可以直接迁移到真实项目中——分享链接时的一个拼写错误就可能把访问者带到错误的地方。

如果发现不一致，记下问题所在并在卡片上修正。随着时间推移，这种手工检查会变得很快，你会自动发现常见错误——比如混淆问号和井号、忘记路径开头的斜杠——而不需要每次都写出完整标注。练习的目的正是通过对安全假设示例的刻意训练来建立这种自动识别能力。

保留这份说明供以后写作或沟通使用

把完成的卡片存放在你写内容或配置链接时实际会查看的地方。项目文件夹里的一个简单文本文件就很合适，因为它与你编辑的其他文件放在一起。如果你偏好笔记应用，可以为每个项目保留一条笔记，把所有地址卡片列在一起以便快速浏览。

当你最终用真实域名和真实路径替换假设示例时，卡片格式保持不变。你更新主机、调整路径以匹配实际页面结构、根据需要添加或删除查询参数和片段。你在这里练习的标注方法原样适用。如果站点增长到包含许多页面，卡片集合同时就是你已规划或已发布的每个地址的清单。

你还可能发现卡片在与他人沟通站点时很有用。与其把一条长URL粘贴到消息中然后指望对方正确解析，不如直接分享带有标注部分的卡片。这在请别人对某个特定页面提供反馈、或向不太熟悉URL结构的人描述链接结构时尤其有帮助。你保留的这份记录是对项目沟通清晰度的一笔小而实际的投入。

常见问题

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

不是。该地址是为拆解练习而编造的假设字符串，不指向任何已上线的页面，也没有服务器预期会对它作出响应。

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

查询跟在问号之后，以键值对形式向服务器提供参数。片段跟在井号之后，相当于返回资源内部的书签，并且不会随请求发送到服务器。²

每次分享URL时都需要写上协议方案吗？

在浏览器地址栏中，浏览器可以在你省略协议方案时填入默认值；但当你在文档中书写URL或与他人分享时，写上协议方案能让地址完整且无歧义。²