在网站上线之前,需要清楚地理解地址的每个组成部分,以便描述、核对和分享时不出错。本文用一个假设的URL来展示网站地址各部分的作用,并说明如何为自己的项目保留一份简单的组成部分记录。
域名与完整URL分别回答什么问题
假设你正在规划一个小型个人项目,想先把地址的各个部分理清楚。你写下这样一个字符串:https://example.org/notes/first-page?view=compact#intro 。这是一个仅用于阅读练习的假设地址,不指向任何真实存在或已上线的页面。把它当作一张标注了各部分名称的示意图来对待,可以把注意力集中在结构本身,而不是这个页面能否打开。
域名回答的问题是「我要访问互联网上的哪台服务器」。域名是互联网基础设施的关键部分,为任何可用的网络服务器提供人类可读的地址,因为IP地址难以记忆并且可能随时间变化。在上面的例子中,example.org就是域名部分,它标识了服务器,但没有指定你想获取该服务器上的哪一项内容。1
完整URL回答的是一个更具体的问题:「浏览器应该在那台服务器上获取哪一项资源,以及在什么条件下获取」。URL是互联网上唯一资源的地址,也是浏览器用来获取已发布资源(如HTML页面、CSS文档和图片等)的关键机制之一。同一个域名可以出现在许多不同的URL中,每个URL指向不同的资源或同一资源的不同视图。标识服务器与标识服务器上某项具体资源之间的区别,正是本文要展开讨论的核心。2
在本例中标出各组成部分
把完整字符串 https://example.org/notes/first-page?view=compact#intro 写在纸上或纯文本文件中,在每个结构边界前画一条线或插入一个空格。方案部分是https,它指示浏览器必须使用哪种协议来请求资源。权威部分从分隔符://之后开始,在这里由域名example.org组成。路径是/notes/first-page,指向该服务器上的一个位置。查询字符串从问号开始,内容为view=compact。片段标识符从井号开始,内容为intro。2
问号是引导查询部分的定界符。问号与井号之间的内容由键值对组成,向网络服务器提供额外参数。本例中只有一个键值对view=compact,但查询字符串可以包含多个用和号分隔的键值对。井号引导片段,片段相当于资源内部的一个书签,为浏览器指明应显示该书签位置处的内容。片段不会随请求一起发送到服务器。2
域名本身也有自己的内部结构。域名由若干部分组成,各部分之间用圆点分隔,从右向左阅读。在example.org中,org是顶级域名,它告诉用户该域名背后服务的一般用途;example是位于顶级域名之前的标签。顶级域名是域名的最后一个组成部分,ICANN指定各组织来管理每个顶级域名。认清这些子部分有助于你日后向不熟悉命名规则的人解释自己的地址。13
保持主机不变,对比不同路径与查询
保持方案和域名不变,只替换路径。字符串 https://example.org/archive/old-draft?view=compact#intro 使用相同的主机,但指向该服务器上不同的位置。路径/archive/old-draft只是写在域名之后的另一条路线。在没有对实际服务器进行测试的情况下,仅凭字符串本身无法判断该路径会返回一个页面、一个错误还是一个重定向;字符串只告诉你正在请求什么。
现在保持路径不变,只更改查询。字符串 https://example.org/notes/first-page?view=full#intro 请求相同的资源路径,但传递了不同的参数值。服务器可能利用这些参数在返回资源之前进行额外处理,每台服务器对参数有自己的规则。仅从地址本身可以观察到参数名称是view、值从compact变成了full,但无法确认服务器是否以及如何区分两者,除非从服务器所有者处获得更多信息。2
最后,只更改片段。字符串 https://example.org/notes/first-page?view=compact#summary 保持方案、主机、路径和查询完全相同,但把书签移到了文档中另一个锚点位置。因为片段不会随请求发送到服务器,这一变化只影响浏览器加载页面后滚动到的位置。将这三个变体并排比较可以清楚地看到,URL字符串的每个部分各自承担不同的角色:路径选择资源,查询传递额外指令,片段定位已加载结果中的阅读位置。2
为假设项目制作地址说明卡
记录地址的用途,用一句话写在说明卡的最上方。对于这个假设项目,用途可以写成:首个笔记页面的紧凑视图,滚动到引言部分。先写明用途,就为后续核对每个部分是否真正支持这一意图提供了一个参照点。
列出每个组成部分,各占一行。方案:https。域名:example.org。路径:/notes/first-page。查询:view=compact。片段:intro。分行书写可以避免把整个字符串当作一个不可区分的整体来对待。如果你的项目最终使用多个地址,为每个地址各建一张说明卡,让各部分不会混淆在一起。
标注每个值的选择理由,写一段简短的说明。例如,你可以注明路径反映了你为内容规划的类文件夹结构,查询参数控制显示密度,片段指向某个特定标题。这些备注是你自己的规划选择,不是任何标准施加的技术要求。它们的存在是为了让说明卡的未来读者——包括几个月后的你自己——能够理解当初的推理过程,而不必从头重新推导。
用手工复制与逐项标记核对说明卡
一次快速的手工核对可以在你把地址分享给别人之前发现拼写错误和定界符位置错误。以下步骤均为普通作者建议,不是任何规范的要求。
下面每一步都可以在纯文本编辑器中完成,不需要任何特殊工具。
如果在任何一步中发现不匹配,立即修正说明卡,而不是留到以后再处理,因为小错误在地址被复制到其他文档时会不断累积。
步骤 1
复制说明卡上的完整URL字符串,粘贴到文本文件的一个空白行中。不要凭记忆重新输入;使用复制功能,这样你核对的就是说明卡上实际包含的内容。
步骤 2
在每个定界符前插入一个空格:在https之后、路径的第一个斜杠之前、问号之前、井号之前。这样就在视觉上将五个组成部分分隔开来,使任何缺失或多余的字符一目了然。
步骤 3
逐项对比每个分隔后的片段与说明卡上对应行的内容。确认方案行与第一个片段匹配,域名行与第二个片段匹配,依此类推直到片段行。如果每个片段都匹配,说明卡与你打算使用的字符串是一致的。
保留说明供以后写作或沟通使用
把完成的说明卡存放在你经常查看的位置,例如项目的说明文件或专门的笔记文件夹。目标不是建立一套正式的文档系统,而是让信息在你下次需要把地址粘贴到模板中、分享给合作者或排查一个行为异常的链接时容易找到。
当项目增长、你添加了更多页面时,为每个新地址重复制作说明卡的过程。随着时间推移,你会拥有一份简短的清单,把每个面向公众的URL映射到它的用途和各部分拆解。这份清单是个人参考;你可以自由选择让复查最快捷的格式,无论是纯文本文件、电子表格中的一行,还是项目管理工具中的一条笔记。
如果你后来决定更改路径或添加查询参数,在更新地址本身的同时更新说明卡。保持说明卡与实际字符串同步,意味着你始终有一个固定的地方可以查看某个特定地址应该做什么。这种即时更新的习惯是一条简单的作者建议,可以防止文档与现实之间在较大项目中逐渐脱节而产生混乱。
常见问题
在示例URL中,查询字符串和片段有什么区别?
查询字符串由问号引导,向网络服务器传递参数,可能影响服务器返回的内容。片段由井号引导,是已加载资源内部的书签,不会随请求发送到服务器。在本例中,view=compact是查询参数,而intro是片段。2
只更改URL中的路径,是否一定意味着浏览器会加载不同的页面?
不一定。路径告诉浏览器要请求哪项资源,但服务器如何响应该请求取决于服务器自身的配置。仅从URL字符串可以观察到请求了不同的资源,但如果不向实际服务器发起测试,无法确认实际结果。
为什么要把URL的各部分分开写下来,而不是只保存完整字符串?
分开书写各部分更容易发现拼写错误、向他人解释地址,以及在不意外改动其他部分的情况下更新某一部分。把完整字符串当作一个整体来对待会隐藏这些边界,使小错误在复查时更难被发现。
What is a Domain Name? - Learn web development | MDN. 采集日期:2026-11-01. ↩︎ ↩︎
What is a URL? - Learn web development | MDN. 采集日期:2026-11-01. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
TLD - Glossary | MDN. 采集日期:2026-11-01. ↩︎