网站上线之前，地址本身已经承载了影响访问者查找和使用内容的信息。本文以一个假设的完整URL为例，逐段拆解每个部分的含义，帮助你在规划自己的项目时清楚知道地址里每一段在做什么。
域名与完整URL分别回答什么问题
假设你正在准备一个小型个人项目站点，并写下 https://example.org/notes/first-page?view=compact#intro 作为规划用的占位地址。这个地址并非真实页面，仅用于练习阅读其结构。首先需要注意的是，这个地址包含两个不同层次的信息。域名部分 example.org 回答的是一个宽泛的问题：互联网上哪台服务器应当处理这次请求？域名是互联网基础设施的关键组成部分，它为互联网上任何可用的Web服务器提供了一个人类可读的地址，因为计算机之间通过数字形式的IP地址通信，而这些地址对人类来说既难以记忆，也难以与特定服务建立关联。1
完整URL回答的是一个更具体的问题：在那台服务器上，浏览器应当获取哪一个确切的资源？URL是互联网上唯一资源的地址，也是浏览器用来获取已发布资源（如HTML页面、CSS文档和图片等）的关键机制之一。如果说域名指向的是整栋建筑，那么完整URL指定的是房间、书架，甚至你想阅读的那一段文字。2
在我们的假设示例中，example.org 标识了服务器，而字符串的其余部分将请求逐步缩小到一个特定页面、一个特定的显示偏好，以及该页面内的一个特定位置。理解这一区别有助于你明白，为什么两个共享同一域名的URL可以指向完全不同的内容。域名是共同的起点，其后的每一部分都在增加具体性。12
在本例中标出地址的各个组成部分
让我们按顺序标注 https://example.org/notes/first-page?view=compact#intro 的每一段。字符串 https 是协议（scheme），它指示浏览器必须使用哪种协议来请求资源。对于网站来说，协议通常是HTTPS或其未加密版本HTTP。字符 :// 将协议与后面的权限（authority）部分分隔开来。2
接下来是 example.org，即域名，它属于权限部分。权限指明了正在请求哪台Web服务器。域名之后，路径 /notes/first-page 告诉服务器应当返回哪个资源。在早期，路径代表服务器上物理文件的位置，但如今它主要是由Web服务器处理的一种抽象，并不对应任何物理实体。问号 ? 引出查询部分，本例中是 view=compact。查询参数是提供给Web服务器的额外键值对，服务器可以利用它们在返回资源之前执行额外处理。最后，井号 # 引出片段（fragment），这里叫 intro。锚点代表资源内部的一种书签，为浏览器指示应显示该书签位置的内容。2
有两个标点符号值得特别注意，因为它们改变了其后所有内容的含义。问号标志着查询参数的开始，问号与井号之间（或字符串末尾）的所有内容都属于查询。井号标志着片段标识符的开始，片段永远不会随请求发送给服务器，这意味着它只影响浏览器在本地显示的内容。分清这两个分隔符可以避免一个常见错误：不小心把参数写在井号之后，那样服务器永远看不到它。2
保持主机不变，对比不同路径与查询
现在保持主机部分 example.org 不变，只改变路径。如果你把 /notes/first-page 换成 /notes/second-page，就是在指向同一台服务器上的不同资源。域名没有变化，浏览器仍然联系同一台机器，但路径告诉那台机器提供不同的内容。这是单个域名承载多个不同页面的最基本方式。
接下来，保持路径不变，只改变查询。把 ?view=compact 写成 ?view=full，资源本身相同，但请求服务器以不同方式处理。由于每台Web服务器对参数有自己的规则，你无法仅凭URL判断服务器实际会如何处理 view=full。字符串告诉你正在请求什么，但并不保证会返回什么。这一区别在为项目记录地址时很重要：记录URL所写的内容，而不是你猜测服务器会做的事情。2
你也可以完全移除片段。去掉 #intro 后，浏览器会从页面默认起始位置加载，而不会滚动到某个书签位置。添加、移除或更改片段不会改变服务器收到的内容，因为片段永远不会随请求发送。将这些变体并排观察，就能具体看到每个部分的角色：路径选择资源，查询添加可选指令，片段在已获取的资源内定位查看位置。2
为假设项目制作一张地址说明卡
记录一张简短的说明卡，写下关于项目地址的三件事：页面的用途、完整的URL字符串，以及各部分的标注分解。对于我们的假设示例，说明卡可以这样写：用途——以紧凑阅读视图显示第一篇笔记，并滚动到引言部分。完整地址——https://example.org/notes/first-page?view=compact#intro。协议——https。主机——example.org。路径——/notes/first-page。查询——view=compact。片段——intro。
这张说明卡是一个单一参考，你可以分享给协作者，也可以在项目发展数月后重新查阅。将用途与技术部分记录在一起，有助于尽早发现不匹配。如果声明的用途说页面显示紧凑视图，但查询写的是 view=full，那就存在不一致，可以在站点上线之前修正。
选择一种容易更新的格式。纯文本文件、文档中的表格，甚至项目管理工具中的一条笔记都可以。重要的是说明卡放在你确实会查看的地方，并且每个部分使用与拆解URL时相同的词汇来标注。一致的标签能减少你以后添加更多页面或参数时的混乱。
用手工复制与逐项标记核对说明卡
一次快速的手工检查可以在问题造成困扰之前发现拼写错误和分隔符位置偏差。以下步骤是作者建议的简单核对流程，不需要任何特殊工具。
完成检查后，将你标注的各段与原始字符串再做一次对比。如果每个字符都有对应，且每个分隔符都在预期位置，说明卡就是一致的。如果不一致，修正说明卡并重复这个过程。这个习惯只需一分钟，但能防止那种在日后撰写文档或与他人分享地址时变得令人困惑的小错误。
检查协议、主机、路径、查询和片段，按此顺序确认每一段在正确的分隔符处开始和结束。具体来说，确认冒号加双斜杠紧跟在协议之后，确认主机后的第一个单斜杠开始路径，确认问号出现在任何查询内容之前，确认井号出现在任何片段内容之前。
步骤 1
将完整URL从说明卡复制到一个空白文本文件中，作为未改动的参照。
步骤 2
手工标记每个分隔符：在 :// 下方画线，圈出开始路径的第一个 /，给 ? 画框，给 # 画框。
步骤 3
大声朗读标记之间的各段内容，并与说明卡上的标签对比。如果某段不匹配，记下差异。
保留这份记录供以后使用
将你的地址说明卡保存在能延续到规划阶段之后的地方。许多首次建站者在搭建过程中创建了有用的笔记，站点上线后却丢失了它们。把说明卡存放在与站点文件相同的仓库或文件夹中，方便你在撰写文档、向协作者解释项目或调试意外行为时快速找到。
当项目从单个页面扩展为多个页面时，将说明卡格式延伸以覆盖每个新地址。一致的结构意味着你可以浏览一组说明卡，快速看出哪些页面共享同一主机、哪些使用了查询参数、哪些依赖片段进行导航。当你需要向没有见过站点结构的人解释时，这种概览尤其有帮助。
你也可以记录自己的记录选择：为什么选择了某种格式，日常引用中是否包含协议，以及是否将片段视为可分享地址的一部分还是内部书签。这些决定因个人和项目而异。把它们写在说明卡旁边，能给未来的你提供理解过去选择所需的背景，而不必猜测。
常见问题
URL中的片段部分会发送给服务器吗？
不会。片段标识符位于井号之后，永远不会随请求发送给服务器。它只告诉浏览器在已获取的资源内滚动或定位到哪个位置。2
相同域名的两个URL能指向不同内容吗？
可以。域名标识了服务器，但路径、查询和片段指定了浏览器应加载哪个资源以及哪种视图。改变其中任何一部分，即使域名不变，也可能导向不同的内容。2
分享URL时需要包含协议部分吗？
在浏览器地址栏中通常可以省略协议，因为浏览器默认使用HTTP。但在书面记录或分享给他人时，包含协议能使完整URL没有歧义。2