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

准备第一个网站时，域名和URL这两个词经常同时出现，但它们回答的是不同层次的问题。本文用一个假设地址演示网站地址各部分的作用，并展示如何为自己保留一份清晰的记录。

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

假设你正在搭建一个小型个人网站，用来发布学习笔记。有人向你询问网站地址，你可能只回答一个域名，比如 example.org，也可能粘贴一条完整地址，例如 https://example.org/notes/first-page?view=compact#intro。这两种回答处于不同的具体程度。域名标识的是互联网上你想访问的那台服务器，而完整URL进一步指明了浏览器应当获取该服务器上的哪一项具体资源。理解这一区别有助于你在与协作者、托管服务商或读者沟通时表达清楚。¹²

域名之所以存在，是因为计算机之间通过IP地址通信，而IP地址是一长串数字，人们很难记住，并且可能随时间变化。域名是IP地址的人类可读别名，方便人们输入、分享和回忆。它的结构从右向左阅读，最右边的顶级域名提供关于服务的一般信息，左边的标签则逐步缩小到某台具体服务器或子域。¹³

URL是互联网上某项唯一资源的地址。它将协议方案、域名以及若干附加部分组合在一起，把请求精确到某个页面、文件或页面内的某个位置。理论上，每条有效的URL指向一项唯一资源。当你分享完整URL而非仅分享域名时，接收者就有足够信息直接到达特定内容，无需再做额外导航。²

在本例中标出各组成部分

要观察URL各部分如何组合，可以看这条假设地址：https://example.org/notes/first-page?view=compact#intro。这条地址并不指向一个真实页面，也没有在任何地方发布。它仅作为一条可供标注和讨论的字符串而存在。把它当作纯粹的阅读练习，可以把注意力集中在结构上，而不涉及任何实际服务器行为。²

第一个组成部分是协议方案，这里写作 https，它告诉浏览器请求资源时应使用哪种协议。下一个组成部分是域名 example.org，用于标识目标网页服务器。协议方案与域名合在一起，构成到达某台特定服务器所需的最少信息。在本例中，权限部分只有 example.org，没有显示端口号，这意味着浏览器将使用HTTPS的标准端口。²

域名之后是路径，写作 /notes/first-page，表示正在请求服务器上的哪项资源。路径之后是查询字符串，由问号引出。本例中 ?view=compact 就是查询部分，包含一个名为 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 参数实际做了什么处理。字符串告诉我们的是正在请求什么，而不是服务器如何响应。

在为自身项目记录地址时，区分观察与推断很重要。你可以可靠地记录两条地址之间哪些部分不同，并用协议方案、域名、路径、查询和片段这些术语描述差异。应当避免的是，在未经测试或文档确认的情况下，假设某个查询值会在服务器上产生特定结果。地址字符串是对请求的描述，而非对结果的保证。

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

记录一张简短的说明卡，为你项目中使用的每条地址建档。对于我们的假设笔记网站，说明卡应包含页面用途、完整地址和各部分拆解。用途可以写成：学习笔记，第一页，紧凑视图。完整地址是 https://example.org/notes/first-page?view=compact#intro。在其下方，列出协议方案为 https，域名为 example.org，路径为 /notes/first-page，查询为 view=compact，片段为 intro。

把说明卡记录成便于快速浏览的格式。每行一项的简单列表就很合适。将完整地址放在最上面，这样需要复制时不必在段落中翻找。地址下方逐项列出各部分及其简短标签。如果项目有多个页面，每条地址建一张卡。随着时间推移，这组卡片就成了快速参考，省去每次分享或排查链接时重新解析长字符串的麻烦。

说明卡的价值不在于写一次这个动作本身，而在于拥有一份稳定的参考，日后可以对照检查。当你更新内容、添加新页面或与协作者分享链接时，说明卡提供一个集中的位置来核实地址各部分是否符合你的预期。它还能帮你发现遗漏的查询参数，或者片段指向了一个你已改名的章节这类问题。

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

手工核对是一个简单的习惯，能在小错误造成困惑之前将其捕获。这个过程不需要任何特殊工具，一个文本编辑器甚至一张纸就够了。目标是确认你记录的地址每个部分都与你打算使用的实际字符串一致。

完成上述步骤后，将你标注的各部分与之前写好的说明卡进行对比。如果每个部分都吻合，说明卡是准确的。如果有任何部分不同，就更新说明卡以反映实际字符串。这个检查只需一分钟，却能防止那种导致链接失效或分享出去的地址无法按预期工作的小差错。

检查你的说明卡，每当你修改项目的地址结构时都应如此。如果你添加了新页面、更改了查询参数或重命名了片段所指向的章节，立即更新对应的说明卡。保持说明卡处于最新状态，意味着你始终有一份可靠的参考，无需凭记忆重建地址。

步骤 1

将完整地址 https://example.org/notes/first-page?view=compact#intro 复制到一个空白文本文档中。确保复制完全精确，没有多余空格或遗漏字符。

步骤 2

标注复制字符串中的每个边界。用方括号或高亮标出协议方案 https，然后标出域名 example.org，接着标出路径 /notes/first-page，再标出查询 view=compact，最后标出片段 intro。为每个标记的部分写上名称。

步骤 3

将你标注的各部分与之前创建的说明卡进行对比。确认协议方案、域名、路径、查询和片段在复制的字符串与说明卡条目之间完全一致。

保留说明供以后使用

说明卡核对完毕后，把它存放在你做项目时自然会查看的地方。项目文件夹里的一个纯文本文件、你常用笔记应用中的一条记录，或者配置文件顶部的一行注释，都可以。格式不重要，重要的是持续性。关键在于你需要分享链接、撰写文档或排查某个页面加载异常时，说明卡就在手边。

随着项目增长，你可能积累多张说明卡。到那时，可以考虑按页面用途或按网站所属板块来组织它们。对于一个小型个人笔记网站，把所有卡片按顺序列在一个文件里通常就够了。对于较大的项目，按板块或按内容类型分组有助于快速找到正确的地址，而不必在无序列表中滚动。

这种做法是个人选择而非技术要求。有人更倾向于依赖浏览器书签或服务器日志，而不是手写说明卡。手写说明卡的优势在于，它不仅记录了地址本身，还记录了你当初的意图。当你隔了一段时间再回到项目时，说明卡提醒你的不仅是地址是什么，还有你为什么这样组织它。这种上下文单靠书签很难恢复。

常见问题

片段部分会随请求发送给服务器吗？

不会。片段出现在井号之后，它充当资源内部的书签，不会随请求一起发送给服务器。它只影响浏览器如何显示已经接收到的内容。²

仅凭阅读URL就能知道服务器如何处理查询参数吗？

不能。查询字符串描述的是正在请求什么，但并不揭示服务器如何处理该请求。你需要实际测试该地址或查阅服务器文档，才能了解某个参数的具体效果。

如果只有一个页面，还需要制作说明卡吗？

不是必须的，但即使只有一张卡也能节省时间。如果日后你添加更多页面或需要向别人分享地址，已经写好的拆解意味着你可以直接解释各部分，而不必从头重新解析字符串。