网站上线之前,地址会出现在规划文档、邮件和配置字段里。许多第一次建站的人把整串字符当作一个不可分割的整体来对待。把它拆成有名称的组成部分,能让每一段更容易检查、沟通和排查问题。

域名回答的问题与完整URL回答的问题

考虑下面这个仅用于讲解的假设地址:https://example.org/notes/first-page?view=compact#intro。这串字符不指向任何真实页面,也没有在任何地方发布过,它存在的目的只是让我们能给每一段贴上标签。当有人问「网站放在哪里」时,答案是域名部分,即example.org。域名是互联网上为Web服务器提供的可读地址,因为原始IP地址对人类来说很难记住,而且可能随时间变化。1

当有人问「那台服务器上的哪个具体资源是我需要的」时,答案就需要完整的URL。URL是互联网上唯一资源的地址,它把协议、服务器身份以及该服务器上某个特定文件或端点的位置组合在一起。域名本身标识的是机器;完整URL则把请求缩小到一个具体的文档、一张图片或一个接口端点。2

这个区分在实际工作中很重要,因为两个协作者可能就域名达成一致,却仍然对具体指哪个页面产生分歧。在上线准备阶段,把域名和每个重要资源的完整URL分别记录下来,可以避免这种混淆。

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

从左到右阅读https://example.org/notes/first-page?view=compact#intro,第一段是方案,即https。方案表示浏览器请求资源时必须使用的协议。对于网站来说,协议通常是HTTPS或其未加密版本HTTP。2

下一段example.org是域名。它位于URL的权限部分,通过://这个字符模式与方案分隔开。域名告诉浏览器要联系哪台Web服务器。在我们的示例中,顶级域是org,它属于不要求背后服务满足特定条件的通用顶级域。12

域名之后是路径/notes/first-page。路径标识服务器上的一个特定资源。在早期互联网历史中,路径对应的是服务器上的物理文件位置,但现在它主要是由Web服务器处理的抽象概念。路径之后,问号引导查询字符串view=compact。查询参数是键值对,服务器可以用它在返回资源之前对响应做额外处理。最后,井号引导片段标识符intro。片段相当于资源内部的一个书签,指示浏览器滚动到特定位置。值得注意的是,片段部分不会随请求一起发送给服务器。2

保持主机不变时对比不同变体

把方案和域名固定为https://example.org,只改变路径,就能观察到地址如何变化:https://example.org/archive/summary。被联系的服务器完全相同,但被请求的资源不同。这正是路径的核心功能——在同一台机器上区分一个文档和另一个文档。2

现在比较https://example.org/notes/first-page?view=compact与https://example.org/notes/first-page?view=full。路径相同,所以目标的基础资源一样,但查询参数不同。服务器可能会利用这个参数来调整返回内容,不过具体行为完全取决于服务器的配置。仅从URL字符串本身,我们只能观察到一个参数被提供了,无法确定服务器会怎样处理它。2

最后,添加或移除片段会改变浏览器在文档内部滚动的位置,但不会改变获取的是哪个资源。https://example.org/notes/first-page#intro和https://example.org/notes/first-page#conclusion指向同一份文档,只是内部书签不同。认清这些边界在调试时很有帮助:如果两个URL只在片段上有差异,服务器收到的请求是完全一样的。2

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

记录一张简短的说明卡,写下这个地址的用途、完整URL以及各部分的拆解。对于我们的假设项目,这张卡可以写成:用途——以紧凑阅读视图打开笔记系列的第一页,并滚动到引言部分。完整地址——https://example.org/notes/first-page?view=compact#intro。方案:https。域名:example.org。路径:/notes/first-page。查询:view=compact。片段:intro。

在说明卡上不仅记录每部分是什么,还要记录为什么这样选择。例如,路径设为/notes/first-page,是因为项目把内容组织在notes目录下,而这是该系列的第一页。查询参数view=compact是为了请求一个简化布局。片段intro是为了让读者直接落在开头部分,不需要手动滚动。

这张卡是个人参考文档,不需要遵循任何外部标准。目标是创建一个集中查看的地方,让你能快速找到这个项目中每一段的含义,这样以后讨论地址时就不必从头重新分析整串字符。

手工核对说明卡

手工核对能发现复制长字符串时容易忽略的转录错误。下面的过程只使用示例地址和你刚写好的说明卡,除了纯文本编辑器之外不需要其他工具。

检查每个分隔符的位置。确认冒号和双斜杠紧跟在方案后面,路径以单个正斜杠开头,问号在任何参数之前恰好出现一次,井号在片段之前恰好出现一次。分隔符放错位置会改变整串字符的含义。

将说明卡与原始字符串逐字符对比至少一次。这是一个简单但有效的习惯,能防止域名或路径中出现不易察觉的拼写错误。

步骤 1

从原始来源把完整URL https://example.org/notes/first-page?view=compact#intro复制到纯文本编辑器中,不要凭记忆重新输入。

步骤 2

在每个过渡点插入空格或括号来标记边界:在https://之后、在example.org之后、在问号之前、在井号之前。

步骤 3

将每个标记出的段与说明卡上对应的字段逐一比较。如果有任何不同,修正说明卡并重新比较。

步骤 4

记录核对日期,并注明说明卡是否无需修改即通过。这个时间戳能帮助你在项目演变后判断说明卡是否仍然适用。

保留说明卡供日后参考

把核对通过的说明卡和其他项目规划文档放在一起。无论放在笔记应用、共享文档还是纯文本文件里,都是个人选择。重要的是这张卡放在你真正会在有人问起地址时去查看的地方。

如果项目增长后出现更多URL,考虑为每个地址单独建一张卡,而不是把多个地址合并到一个区块里。独立的卡片更容易单独更新,也减少了误改其他条目的可能性。

当需要把地址分享给协作者或粘贴到配置字段时,可以查阅说明卡而不是凭记忆重新拼凑字符串。这个小习惯能降低发布时引入拼写错误的概率,也能在日后有人问起地址各部分的意图时提供清晰的参考。

常见问题

在示例URL中,把片段从#intro改成#conclusion,服务器收到的请求会不同吗?

不会。片段标识符不会随请求一起发送给服务器。它只告诉浏览器在资源加载完成后滚动到文档内的哪个位置。2

两个不同的URL可以共享同一个域名但指向完全不同的内容吗?

可以。域名标识的是服务器,但路径决定的是请求该服务器上的哪个资源。同一域名下不同的路径可以返回完全不同的文档。2

规划网站时为什么要把域名和完整URL分开记录?

域名从整体上标识服务器,完整URL则指定一个确切的资源。在笔记中把它们分开,能清楚地表明当前讨论的是整台服务器还是服务器上的某个具体页面或文件。12