网站上线之前，地址会出现在规划文档、草稿和合作者的对话中。分清哪一段是域名、哪一段是路径、哪一段是可选参数，能帮助你准确描述自己的站点，避免分享链接时产生混淆。本文用一个明确标注为假设的地址，逐步拆解每个组成部分。
域名回答什么问题，完整URL回答什么问题
我们使用这个假设地址作为全文的拆解对象：https://example.org/notes/first-page?view=compact#intro。这个地址不指向任何真实页面，也没有在任何地方发布，它存在的唯一目的是让我们标注每一段并理解各自的角色。其中的域名部分是 example.org。域名为互联网上任何可用的网络服务器提供人类可读的地址，因为计算机底层使用的 IP 地址既难以记忆，也可能随时间变化。1
完整的 URL 则回答一个更具体的问题：浏览器应当从该服务器上获取哪一项资源？URL 是互联网上唯一资源的地址，也是浏览器用来获取 HTML 页面、CSS 文档、图片等已发布资源的关键机制之一。因此，域名告诉你该连接哪台服务器，而完整的 URL 告诉你请求的是该服务器上的哪一个具体页面、文件或片段。在我们的例子中，域名 example.org 标识服务器，其后的所有内容将请求缩小到一项具体资源。2
这个区别在你准备上线时很有实际意义。如果有人问你的域名是什么，他需要的是那个简短、易记的标识符；如果他问某个特定页面的 URL，他需要的是包含路径和附加参数的完整字符串。在对话或文档中混淆这两者，可能导致链接失效或请求指向错误的位置，所以从一开始就保持精确是值得的。
在示例中标出每个组成部分
回到我们的假设字符串，逐一标出每个组成部分。第一段是 https，即协议方案，它指示浏览器必须使用哪种协议来请求资源。对于网站而言，协议通常是 HTTPS 或 HTTP。接下来是 example.org，这是包含域名的权限部分。域名的结构由若干部分组成，以点号分隔，从右向左阅读，最右边的部分是顶级域名。在本例中，org 是顶级域名，example 是紧挨其前的标签。21
权限部分之后是路径，在本例中为 /notes/first-page。路径表示资源在网络服务器上的位置。在早期互联网中，这样的路径代表服务器上的物理文件位置，而如今它大多只是由服务器处理的抽象概念，并不对应真实的物理路径。路径之后是查询字符串 ?view=compact。问号标志着查询的开始，查询以键值对的形式向服务器提供额外参数。这里键是 view，值是 compact。2
最后，井号引出片段标识符，在本例中为 intro。片段相当于资源内部的一个书签，为浏览器提供指引，使其显示该书签位置的内容。值得注意的是，井号之后的部分也就是片段标识符，永远不会随请求发送到服务器。因此完整的拆解结果是：协议方案 https，域名 example.org，路径 /notes/first-page，查询 view=compact，片段 intro。每个分隔符都有特定角色：问号引出查询，井号引出片段。2
保持主机部分不变，对比不同路径和查询
为了观察各部分如何独立运作，保持协议方案和域名不变，仍为 https://example.org，只改变路径。如果写成 https://example.org/about，我们请求的就是同一台服务器上的另一项资源。域名没有变化，浏览器仍然联系同一台服务器，但路径现在指向服务器与 /about 关联的资源。类似地，https://example.org/notes/second-page 会请求同一 notes 目录下的另一项资源。我们并不声称这些页面真实存在，只是在观察字符串如何改变含义。
现在保持路径不变，只改变查询字符串。地址 https://example.org/notes/first-page?view=full 使用与原始示例相同的路径，但为 view 参数传递了不同的值。服务器可以利用这些参数在返回资源之前进行额外处理。每台服务器对参数有自己的规则，因此我们无法假设服务器对 view=compact 和 view=full 会做出什么不同的响应。我们只能观察到字符串不同，并且这种差异通过查询部分传达给服务器。2
片段的情况又如何？将 #intro 改为 #summary 不会改变服务器收到的内容，因为片段永远不会随请求发送。它只影响浏览器在已获取文档中滚动到的位置。这意味着两个仅在片段上不同的 URL 指向同一项服务器资源，但可能显示文档中不同的位置。对你自己的规划而言，这个区别有助于判断地址的差异究竟代表一个真正不同的页面，还是同一页面上的不同滚动位置。2
为假设项目制作一张地址说明卡
记录一张简短的说明卡，为你项目中将要使用的每个地址各建一张。对于我们的假设示例，卡片可以这样写：目的：带紧凑视图和引言书签的主笔记页面。完整地址：https://example.org/notes/first-page?view=compact#intro。协议方案：https。域名：example.org。路径：/notes/first-page。查询：view=compact。片段：intro。这种格式让每个组成部分一目了然，方便你日后复制链接或与合作者分享时发现错误。
用通俗语言记录目的，而不是技术术语。如果该页面旨在以紧凑布局展示项目笔记列表，就照实写。目的栏是给阅读卡片的人看的，不是给解析 URL 的机器看的。当你有多个页面时，每张卡片对应一个地址，这样你可以并排比较，注意到两张卡片是否共享同一域名但路径不同，或者某张卡片有查询参数而另一张没有。
保持卡片格式足够简单，让你真正会去维护它。纯文本文件、电子表格的一行、或项目管理工具中的一条笔记都可以。重要的是每个地址都有自己的条目，使用相同的一组字段，这样几周后回来时你能立刻看出每一部分的意图，而不必从头重新分析字符串。
手工核对说明卡
检查你的说明卡与实际地址字符串是否一致，方法是将完整 URL 复制到一行空白处，逐字符标出每个边界。从左开始：确认协议方案在哪里结束（冒号加双斜杠处），域名在哪里结束（权限部分之后的第一个单斜杠处），路径在哪里结束（问号或井号中先出现的那个），查询在哪里结束（井号或字符串末尾），片段从哪里开始（紧跟井号之后）。这种手工走查能发现仅凭一瞥容易忽略的拼写错误和分隔符错位。
记录你在卡片与实际字符串之间发现的任何差异。如果卡片上写路径是 /notes/first-page，但复制出来的字符串显示 /notes/firstpage 缺少连字符，立刻更新卡片。缺少一个连字符或大小写位置不对这样的小差异，可能导致完全不同的资源或错误，具体取决于服务器的配置方式。不要假设服务器会对这类差异宽容处理。
列出每个查询参数的键值对，单独确认它们与卡片记录一致。在我们的例子中只有一个键值对 view=compact，但实际项目往往会积累多个。如果你发现卡片上有而字符串中没有的参数，或者字符串中有而卡片上没有的参数，在把地址分享给别人之前先解决这个不匹配。
步骤 1
从浏览器地址栏或你的笔记中复制完整 URL 到一行空白文本，确保没有字符被截断或多余添加。
步骤 2
标注边界：在协议方案之后、域名之后、问号之前和井号之前各放一个空格或视觉分隔符。
步骤 3
将每个标记出的片段与说明卡上对应的字段逐一比较，记录任何差异。
步骤 4
更新卡片或地址使两者一致，然后再重复检查一遍以确认修正无误。
保留这份记录供以后使用
把完成的说明卡存放在你撰写内容、设置导航或向他人解释站点时会回头查看的位置。记录的价值不仅在于初次创建，更在于日后出现问题时有一个可靠的参照。如果合作者问该链接到哪个 URL，你可以指向卡片，而不必凭记忆重新拼凑地址。如果你因为站点结构变化需要更新路径，卡片能告诉你具体该修改哪个组成部分。
自行决定记录需要多详细。对于单页个人网站，一张卡片可能就够了。对于有多个栏目的项目，你可以为每个公开页面各建一张卡片，放在同一个文件里。详细程度取决于项目的复杂程度和你预计多久需要查阅一次这些地址，没有外部要求规定特定的格式或数量。
当你的网站最终上线时，这些卡片就变成一份快速核查清单，用来验证你记录的每个地址是否按预期正常访问。你可以逐一打开每个地址，确认内容与你写下的目的一致，标记任何看起来不对的地方。这最后一步是一个简单的习惯，能在读者遇到问题之前帮你发现它们，花费的不过是几分钟仔细阅读。
常见问题
域名和URL是同一个东西吗？
不是。域名标识网络服务器，而完整的 URL 指定该服务器上的具体资源，包括路径、可选的查询参数和可选的片段。域名是 URL 中的一个组成部分。12
改变URL中的片段部分会向服务器请求不同的页面吗？
不会。片段标识符出现在井号之后，永远不会随请求发送到服务器。它只告诉浏览器在已获取的文档中滚动到哪个位置。2
上线之前需要理解所有可能的URL格式吗？
不需要。URL 还有一些额外的部分和规则，但它们与普通用户或正在搭建功能站点的开发者无关。理解协议方案、域名、路径、查询和片段，就足以覆盖你在规划和分享自己地址时需要知道的内容。2