如果你正在准备第一个网站，地址栏里那一长串字符可能看起来毫无规律。本文用一个假设地址逐段拆解，说明每一部分分别回答什么问题，让你能够自信地阅读、记录和核对地址。
域名回答什么问题，完整URL又回答什么问题
假设你正在规划一个小型个人笔记站点。你还没有搭建任何内容，但想先弄清楚将来要分享的地址长什么样。本文通篇使用的完整地址是 https://example.org/notes/first-page?view=compact#intro。这是一个纯粹用于拆解演示的假设字符串，不指向任何真实页面，也从未上线发布。
域名回答的问题是：我应该连接哪台服务器？域名是互联网基础设施的关键组成部分，它们为互联网上任何可用的网络服务器提供人类可读的地址。计算机能轻松处理IP地址，但人们很难记住这些数字，域名正是为了解决这个问题。在我们的例子中，域名是 example.org。其中TLD即最后一个点之后的部分，告诉用户该域名背后服务的一般用途。最通用的TLD如.com、.org和.net不要求网络服务满足任何特定条件。1
完整URL回答的是一个更具体的问题：在那台服务器上，我到底要哪一个资源？URL是互联网上唯一资源的地址，也是浏览器用来获取已发布资源（如HTML页面、CSS文档和图片等）的关键机制之一。理论上每个有效URL都指向一个唯一资源。因此，域名把你带到正确的建筑，而URL的其余部分告诉服务器要打开哪个房间、看哪个货架。2
在例子中标出地址的每一个部分
标注完整地址 https://example.org/notes/first-page?view=compact#intro 的各个部分。从左往右看，https是方案（scheme），表示浏览器请求资源时必须使用的协议。对于网站来说，协议通常是HTTPS或HTTP。接下来是权限部分（authority），通过 :// 这个字符组合与方案分隔。在本例中权限部分就是 example.org，即域名，指示请求的是哪台网络服务器。2
权限部分之后是路径，在本例中为 /notes/first-page。路径代表网络服务器上的资源位置。在早期互联网中，这样的路径代表服务器上的物理文件位置，但现在它主要是由网络服务器处理的一种抽象，没有对应的物理实体。路径之后，问号标志着查询部分的开始。这里查询是 view=compact。查询参数是提供给网络服务器的额外参数，以键值对形式排列。服务器可以利用这些参数在返回资源之前做额外处理。2
最后，井号引出片段（fragment），在本例中为 intro。锚点相当于资源内部的一个书签，为浏览器指明应显示该书签位置的内容。井号之后的部分也称为片段标识符，它不会随请求一起发送到服务器。这意味着片段纯粹是浏览器端的指令，用于在已加载的文档内滚动或跳转到特定位置。2
相同主机、不同字符串：对比路径与查询
现在保持方案和主机不变，只改变路径。如果把 /notes/first-page 换成 /notes/second-page，域名和方案完全相同，但字符串现在指向同一服务器上的另一个资源位置。你并没有对服务器实际如何处理这些路径做任何断言；你只是在观察权限部分之后的字符串有所不同。这个区别很重要，因为共享同一主机的两个地址不一定表现相同，仅凭字符串无法预测服务器行为。
接下来保持路径不变，只改变查询。对比 https://example.org/notes/first-page?view=compact 与 https://example.org/notes/first-page?view=full。路径没有变化，所以资源位置的字符串相同，但查询参数携带了不同的值。根据URL的结构规则，每台网络服务器对参数有自己的处理规则，要确认某台服务器是否处理特定参数，唯一可靠的方式是询问该服务器的所有者。这意味着仅从地址字符串可以识别正在请求什么，但无法确认服务器将如何响应。2
你还可以完全去掉片段，观察地址仍然是一个完整的URL。片段是可选的；它的缺失只意味着没有指定特定的滚动位置。这个观察进一步说明URL由不同部分组成，有些是必需的，有些是可选的。方案和权限是核心必需部分；路径、查询和片段则增加了可能出现在也可能不出现在某个地址中的具体层次。2
为假设项目制作一张地址说明卡
记录这个地址的用途，用一句话概括。对于这个假设项目，用途是：个人笔记集合中第一页的精简视图。这句话捕捉了你的意图，让未来的读者或协作者无需解析原始字符串就能快速了解背景。
在说明卡的下一行写出完整地址：https://example.org/notes/first-page?view=compact#intro。然后在下方逐条列出每个部分及其标签。方案：https。主机：example.org。路径：/notes/first-page。查询：view=compact。片段：intro。这种结构化排版方便日后发现错误，因为你可以将每个标注的部分与原始字符串逐一对比。
补充一段简短说明，标明哪些部分是你刻意选择的，哪些是你接受的默认值。例如，你选择了路径 /notes/first-page 因为它反映了你的内容组织方式。你选择了查询 view=compact 因为你想要精简显示。片段 intro 是可选的，仅用于标记起始滚动位置。记录这些选择有助于你向他人解释地址的含义，也提醒你哪些部分承载意义、哪些只是附带信息。
手工核对说明卡
检查说明卡的方法是从一个独立来源（如文本文件或消息）复制完整地址，逐字符粘贴到说明卡旁边进行对比。不要仅凭目视扫描；一个放错位置的斜杠或一个遗漏的问号都会改变字符串的含义。这个手工复制步骤是简单的作者建议，能在地址公开分享之前捕获拼写错误。
用与说明卡相同的方案、主机、路径、查询和片段分类，对粘贴副本的每个片段进行标注。如果任何片段与说明卡条目不匹配，立即更正。特别注意边界字符：分隔方案与权限的冒号和双斜杠、开始路径的斜杠、开始查询的问号、开始片段的井号。这些边界字符是转录错误最常见的来源。
将核对过的说明卡作为唯一参考，无论你是在文档中写入地址、与协作者分享，还是将其嵌入其他文档。保留一份经过验证的副本可以减少每次凭记忆重新输入地址时引入新错误的机会。如果地址将来发生变化，先更新说明卡，再将修正后的版本传播到所有其他位置。
保留记录供日后写作与沟通使用
将地址说明卡与项目笔记放在一起，这样在撰写文档、在消息中分享链接或向他人解释站点结构时随时可用。说明卡的格式意味着你不必每次重新推导每个部分的含义；标签已经在那里了。如果你计划以后创建更多页面，这一点尤其有用，因为你可以将新地址与说明卡对比，确保路径命名保持一致。
决定说明卡的哪些部分你会公开分享，哪些留作内部参考。例如，你可能与协作者分享完整URL，但将片段保留为只有你自己使用的内部书签。或者你可能在个人简介中只分享域名，而将完整路径和查询保存在项目文档中。这些是组织选择而非技术要求，你可以随项目发展自由调整。
随着项目增长定期回顾说明卡。如果你添加了新页面，检查路径结构是否仍然反映你的内容组织方式。如果你更改了查询参数，更新说明卡使其保持准确。目标是维护一份与实际地址结构同步的活文档，而不是让它变得过时和误导。少量定期关注就能让说明卡在整个项目周期内保持有用。
常见问题
例子中的地址 https://example.org/notes/first-page?view=compact#intro 是一个可以访问的真实页面吗？
不是。这个地址完全是假设的，仅用于演示如何标注URL字符串的各个部分。它不指向任何已上线的页面，也从未被发布。
为什么井号后面的片段部分不会到达服务器？
片段标识符是浏览器端的指令。浏览器用它来滚动或跳转到已加载文档内的特定位置，因此它不会包含在发送给服务器的请求中。2
仅凭阅读URL中的查询参数，能否预测服务器会做什么？
不能。每台网络服务器对参数有自己的处理规则，要确认某台服务器是否处理特定参数，唯一可靠的方式是询问该服务器的所有者。字符串告诉你正在请求什么，但不告诉你服务器将如何响应。2