在准备发布网站之前,你会频繁遇到两个紧密相关的术语:域名和URL。它们在浏览器地址栏里看起来很像,但各自回答的问题不同。本文通过一个假设地址的拆解练习,展示如何识别每个组成部分,让你在规划、记录和沟通自己项目的地址时更有把握。
域名与完整URL分别回答什么问题
假设你正在准备一个小型个人项目,想给它一个网络地址。域名回答的是这样一个问题:互联网上的哪台服务器应该处理我的请求?域名为互联网上任何可用的网络服务器提供了一个人类可读的地址,因为计算机底层使用的IP地址既难以记忆,也可能随时间变化。在我们的假设例子中,域名是example.org。仅凭这个字符串,浏览器就知道该联系哪台服务器,但它并没有说明你想要那台服务器上的哪个具体页面或文件。1
完整URL回答的是一个更宽泛的问题:我想要哪个唯一资源,浏览器应该怎样获取它?URL是互联网上唯一资源的地址,也是浏览器用来检索已发布资源(如HTML页面、CSS文档和图片等)的关键机制之一。因此,域名指向服务器,而完整URL指向该服务器上的某个特定文档或端点。我们的假设地址 https://example.org/notes/first-page?view=compact#intro 就是一个完整URL。它指定了服务器,标明了具体路径,附加了查询指令,并标记了文档内的一个位置。这个练习纯粹是为了阅读和标注字符串,我们不声称这个页面真实存在或已经上线。2
从一开始就保持这个区分清晰,可以避免一个常见困惑。当有人说“我的域名是example.org”时,他指的是服务器。当有人分享一个完整URL时,他指向的是该服务器上的某个特定资源。本文余下部分将用上面这个假设地址来展示每个部分如何组合在一起。
在假设地址中标出各个组成部分
把完整字符串 https://example.org/notes/first-page?view=compact#intro 写在一行空白处,逐段标记。第一个片段 https 是协议方案,它指示浏览器必须使用什么协议来请求资源。对于网站,协议通常是HTTPS或其未加密版本HTTP。紧随其后的是权限部分,由 :// 这个字符模式与协议方案分隔。在我们的例子中,权限部分是 example.org,即域名,表示正在请求哪台网络服务器。2
权限部分之后是路径 /notes/first-page。路径代表资源在网络服务器上的位置。在早期,这样的路径代表服务器上的一个物理文件位置,但如今它大多是由服务器处理的抽象概念,没有对应的物理实体。接下来是查询字符串,由问号引导。在我们的例子中查询是 view=compact。参数是提供给服务器的额外键值对,问号是将路径与这些参数分隔开的定界符。最后,井号引导片段,在我们的例子中是 intro。锚点相当于资源内部的一个书签,为浏览器提供指示,让它显示该书签位置的内容。井号之后的部分永远不会随请求发送给服务器。2
总结标注结果:https 是协议方案,example.org 是权限部分中的域名,/notes/first-page 是路径,?view=compact 是查询字符串,#intro 是片段。问号始终标志查询的开始,井号始终标志片段的开始。记住这两个定界符,就能顺利解析你遇到的任何URL。
保持主机不变,对比不同路径和查询字符串
现在保持主机部分 example.org 不变,只改变路径。比较 https://example.org/notes/first-page 与 https://example.org/gallery/summer-2025。协议方案和域名完全相同,只有路径不同。这意味着两个地址指向同一台服务器,但请求的是不同资源。你纯粹通过阅读字符串就能观察到这一区别。我们不对服务器实际返回什么或如何处理这些路径做任何推断。
接下来,保持路径不变,只改变查询字符串。比较 https://example.org/notes/first-page?view=compact 与 https://example.org/notes/first-page?view=full。协议方案、域名和路径全部相同,只有查询参数的值发生了变化。这说明两个地址指向相同的资源位置,但随请求附带了不同的指令。同样,我们在这里只是阅读字符串结构,不推断服务器如何处理这些指令。
最后看片段。比较 https://example.org/notes/first-page#intro 与 https://example.org/notes/first-page#conclusion。协议方案、域名、路径以及任何查询都相同,只有片段不同。因为片段永远不会发送给服务器,改变它不会改变服务器收到的请求,它只是告诉浏览器在已加载的文档内滚动或定位到哪个位置。认识到这一区别有助于理解为什么分享一个带片段的链接可能让访问者落在同一页面的不同位置。
为你的假设项目制作一张地址说明卡
记录一张简短的地址说明卡。地址说明卡是你保存在项目文件旁边的一条简单笔记,写明地址的用途、完整URL以及每个部分代表什么。对于我们的假设项目,这张卡可以这样写:用途是个人笔记页面;完整地址是 https://example.org/notes/first-page?view=compact#intro;协议方案是 https;域名是 example.org;路径是 /notes/first-page;查询是 view=compact;片段是 intro。
这张卡的价值在于它迫使你明确命名每个组成部分。当你之后需要与合作者分享地址、撰写文档或排查链接问题时,可以回头查看这张卡,而不必猜测字符串的哪个部分起什么作用。如果你的项目最终使用真实域名,卡的结构保持不变,只是域名的值会改变。
选择一种你容易维护的格式。有人喜欢在项目文件夹里放一个纯文本文件,有人喜欢在表格里加一行。格式本身不太重要,重要的是每次为项目添加新地址时都养成填写每个字段的习惯。留下空白字段是一个信号,说明你尚未确认字符串的那个部分代表什么。
手工核对你的地址说明卡
手工核对是在公开分享地址之前发现拼写错误或误判片段的可靠方法。这个过程不需要特殊工具,只需要仔细阅读。
检查每个定界符的顺序。确认冒号加双斜杠的模式恰好出现一次,将协议方案与权限部分分隔。确认第一个问号出现在路径之后、任何查询参数之前。确认井号(如果存在)出现在查询字符串之后,或者在没有查询时直接出现在路径之后。
将卡上的条目与原始字符串逐字符对比。路径中少一个斜杠、多一个空格或字母顺序颠倒,都可能产生一个完全不同的地址。这一步虽然琐碎但耗时很短,能在造成混淆之前抓住最常见的错误。
步骤 1
将地址说明卡上的完整URL复制到一个纯文本编辑器中。
步骤 2
在字符串正上方逐段标注:分别写上协议方案、域名、路径、查询和片段,对应各自的片段。
步骤 3
将你的标注与卡上的字段逐一比较。如果任何标注与对应卡片字段不一致,先修正卡片再继续。
保留这份记录供以后使用
地址说明卡核对完毕后,把它存放在项目演进时你自然会查看的地方。如果你用文本文件记录项目笔记,就把卡附在那里。如果你使用任务看板,就把它挂在相关任务上。目标不是建立一套复杂系统,而是让地址及其拆解说明有一个共同存放的位置。
当你最终撰写内容、分享链接或向他人描述项目时,这张卡为你提供了现成的参考。你可以快速解释为什么选择了某个路径、查询参数控制什么、或者片段为什么指向某个特定章节。这在协作时尤其有用,因为它消除了关于地址哪个部分是有意为之、哪个可能是拼写错误的歧义。
随着时间推移,如果你的项目扩展到包含多个页面或板块,你可能会积累多张地址说明卡。每张卡遵循相同的结构,因此一起回顾它们很容易发现不一致之处,比如某个页面使用了与其他页面不同的查询约定。当地址数量超出记忆范围时,记录和核对的习惯最能体现价值。
常见问题
在示例地址中,片段 intro 会被发送给服务器吗?
不会。URL中井号之后的部分称为片段标识符,它永远不会随请求发送给服务器。它只是告诉浏览器在已加载的文档内将视图定位到哪里。2
URL中问号和井号的区别是什么?
问号将路径与查询字符串分隔开,查询字符串携带传递给服务器的额外参数。井号将查询或路径与片段分隔开,片段是文档内的书签,不会发送给服务器。2
如果只改变URL中的路径而保持域名不变,是否仍然指向同一台服务器?
是的。域名决定了联系哪台服务器。改变路径是在同一台服务器上请求不同的资源,但目标服务器保持不变。2
What is a Domain Name? - Learn web development | MDN. 采集日期:2026-11-01. ↩︎
What is a URL? - Learn web development | MDN. 采集日期:2026-11-01. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎