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

网站上线之前，地址通常只是纸上或笔记文件里的一串字符。理解这串字符中每一部分代表什么，有助于与协作者清晰沟通、正确填写配置字段，并避免混淆域名本身与指向具体页面的更长地址。本文以一个假设地址为例，逐步拆解。

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

假设你正在规划一个小型个人项目，在便签上写下了地址 https://example.org/notes/first-page?view=compact#intro。这是一个纯粹用于拆解练习的假设字符串，该页面不需要真实存在于任何地方。面对这串字符，你已经可以提出两个不同的问题。第一个问题是：互联网上哪台服务器应当处理我的请求？答案藏在域名部分，即 example.org。域名的存在是因为计算机通过数字形式的IP地址进行通信，而IP地址对人来说难以记忆且可能随时间变化，因此引入了人类可读的名称作为更友好的上层标识。¹²

第二个问题是：到达那台服务器之后，我具体想要哪个资源？完整URL回答的是这个问题。URL是互联网上某个唯一资源的地址，也是浏览器用来获取已发布资源（如HTML页面、图片或样式表）的关键机制之一。在我们的示例中，URL不仅指明了服务器，还通过路径、查询和片段进一步限定了浏览器应当请求什么内容，以及应当在结果页面的哪个位置查看。³

在上线之前把这两个问题分开很有用，因为配置任务往往只涉及其中之一。设置托管时你处理的是域名；在页面内写链接或向朋友分享某篇具体文章时，你处理的是完整URL。把两者混在一起容易造成困惑，因此本文余下部分将它们视为不同的对象，并逐一标注每一部分。

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

把完整字符串 https://example.org/notes/first-page?view=compact#intro 写在新的一行上，逐段标注名称。方案（scheme）是 https，它告诉浏览器请求资源时应当使用哪种协议；对于普通网站，协议通常是HTTPS或其未加密的前身HTTP。权威部分（authority）紧跟在分隔符 :// 之后，在本例中由域名 example.org 组成。这里没有出现端口号，这是正常的，因为标准HTTPS连接使用浏览器自动假定的默认端口。³

权威部分之后是路径 /notes/first-page。路径指向Web服务器上的一个资源。在早期互联网中，路径通常对应服务器上的物理文件位置，但如今它主要是由服务器软件处理的抽象概念。问号 ? 引出查询字符串 view=compact。查询参数是键值对，在服务器返回资源之前向其提供额外信息。最后，井号 # 引出片段 intro。片段相当于资源内部的书签，指引浏览器跳转到页面上的特定位置，而不是向服务器请求不同的内容。³

把这些标签记录在字符串旁边的笔记中：方案 = https，主机 = example.org，路径 = /notes/first-page，查询 = view=compact，片段 = intro。把标签写下来之后，后续的对比会容易得多，因为你可以精确指出哪一部分发生了变化、哪一部分保持不变。

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

现在保持主机 example.org 不变，为同一个项目设想两个替代地址。第一个可以是 https://example.org/notes/second-page?view=compact#intro，第二个可以是 https://example.org/notes/first-page?view=full#intro。在第一个替代地址中，只有路径不同：second-page 替换了 first-page。在第二个替代地址中，只有查询值不同：full 替换了 compact。三个字符串的方案、主机和片段完全相同。

在字符串层面观察这些差异，是我们在不向真实服务器发送请求的情况下所能做的全部。路径、查询和片段是浏览器包含在请求中或在收到响应后本地使用的文本。服务器对某个特定路径或查询值的处理方式完全取决于该服务器自身的配置，两台不同的服务器可能以完全不同的方式处理相同的字符串。对于规划和文档记录而言，重要的是你能够识别自己正在修改字符串的哪一部分，并准确描述这一变化。

这种区分在与他人讨论网站时非常实用。说“我修改了查询参数”比说“我改了地址”更精确，它告诉协作者主机、方案和路径都没有动，把讨论范围缩小到一个键值对上。同样的逻辑也适用于在缺陷报告或支持请求中比较两个URL：指出具体哪一段不同，能为所有参与的人节省时间。

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

用简单的卡片格式把你对计划地址所了解的一切集中记录在一处。卡片至少应包含四个字段：用平实语言说明页面用途、完整URL字符串、各部分的标注列表，以及关于每部分预期作用的备注。对于我们的假设项目，用途可以写成“集合中第一篇笔记的精简阅读视图”。完整URL就是我们一直在分析的那串字符。标注部分是前面识别出的五个片段。备注栏可以放简短提醒，例如“view=compact 用于加载简化布局”或“#intro 应滚动到开头部分”。

这张卡片的价值不在于格式本身，而在于养成在需要之前就写下来的习惯。当你之后配置内容管理系统、编写导航链接或向朋友分享预览地址时，可以回头查看卡片，而不必凭记忆重新拼凑地址。如果项目增长并添加了更多页面，每个新地址各有一张卡片，卡片集合就成为你网站结构的轻量地图。

选择你觉得自然的工具来存放这些卡片。纯文本文件很好用，因为方便复制和与先前版本做差异对比。电子表格自动为每个字段提供列。纸质笔记本也可以，只要你之后还能认出自己的字迹。重要的决定是选定一个地方并保持一致，这样未来的你无需在零散笔记中翻找就能找到信息。

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

在将卡片用于任何配置或沟通之前，先对照实际字符串检查一遍。路径片段中的一个小拼写错误或遗漏的问号，都可能产生一个看起来几乎正确却指向意外位置的地址。下面的核对流程是作者建议的习惯，不是任何标准施加的技术要求。

完成这些检查后，将你标注的版本与原始卡片条目进行比对。如果每个标签都匹配，复制过程中没有遗漏任何字符，那么这张卡片就足够可靠，可以用于下一步操作，无论是编写HTML中的链接元素、将地址粘贴到配置字段，还是在消息中分享给协作者。

每次编辑地址时都重复这一核对。即使只改动了一个字符，比如添加末尾斜杠或重命名路径片段，也值得重新走一遍相同的步骤。代价只是几秒钟的注意力，收获是在错误还容易修复时就将其发现。

步骤 1

从卡片上将完整URL逐字符抄写到一行空白文本中，不要使用粘贴功能。这会迫使你审视每一个符号。

步骤 2

标注每个结构字符的位置：方案之后的冒号和双斜杠、开始路径的第一个斜杠、开始查询的问号，以及开始片段的井号。

步骤 3

在抄写字符串的正上方或正下方，为每个片段写上对应的标签，使标签与相应文字对齐。

保留这份记录供以后使用

把完成的卡片存放在你工作时自然会查看的地方。如果你把项目笔记放在某个特定文件夹或应用中，地址卡片就应该和内容草稿、配置笔记放在一起。目标是减少需要查找的地方数量，当你需要回忆某个特定URL的用途时能够快速找到。

随着时间推移，你可能会发现一些卡片因页面重命名、查询参数增加或片段移到不同位置而变得过时。遇到这种情况时更新卡片，而不是另建一份副本。一份持续维护的记录比散落在不同文件中的多个片段版本更值得信赖。如果你偏好版本历史，把文件放在能追踪变更的位置，就能看到地址在早期阶段的样子，同时不丢失当前状态。

这一做法可以自然扩展。只有少数页面的个人博客可能只需要几张卡片，而较大的文档项目可能积累几十张。无论哪种情况，底层习惯都是一样的：写下每个地址的含义，标注其各部分，对照字符串验证标签，并把记录保存在一个一致的地方。上线前花在这套流程上的几分钟，会在你或协作者每次需要引用、排查或解释某个具体页面位置时得到回报。

常见问题

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

不是。域名标识的是服务器，而URL是包含方案、路径以及可选查询和片段的完整地址。域名只是URL中的一个组成部分。¹³

井号后面的片段部分会发送给服务器吗？

不会。片段标识符由浏览器在本地使用，用于导航到已加载资源中的特定位置；它不包含在发送给服务器的请求中。³

URL中需要写端口号吗？

通常不需要。如果Web服务器使用HTTP或HTTPS的标准端口，端口号会从URL中省略，浏览器自动假定默认值。只有当服务器使用非标准端口时才需要显式写出端口号。³