当你准备把一组页面链接交给协作者或存档备查时,最常见的困惑是分不清域名和完整地址各自说明了什么。本文通过一个假设地址逐一标注每个部分,并建立一种可复用的记录习惯。
域名与完整URL分别回答什么问题
假设你正在为一个小型项目站点交接页面链接。同事问“地址是什么”,你可能只回复域名如 example.org,也可能粘贴一段包含路径、问号和井号的长字符串。两种回答在不同场景下都成立,但在记录链接时区分它们很重要。域名为互联网上的网络服务器提供人类可读的地址,它标识了你想访问的服务器,但本身并不指向该服务器上的某个具体页面或资源。1
URL则是互联网上某个唯一资源的地址,是浏览器用来获取已发布资源(如HTML页面、CSS文档或图片)的关键机制之一。域名回答的是“哪台服务器”,而完整URL回答的是“那台服务器上的哪个具体资源,以及用什么方式请求它”。这就是为什么交接清单应当记录完整URL,而不仅仅是域名部分。2
本文全文使用的练习地址是 https://example.org/notes/first-page?view=compact#intro。这个地址不代表任何真实存在的页面,它仅用于练习阅读和标注URL字符串的各个部分。请把它当作项目简报或设计文档中可能出现的一条示例。
在本例中标出各组成部分
把完整字符串 https://example.org/notes/first-page?view=compact#intro 写在一行空白处,标出各部分之间的边界。方案部分是 https,表示浏览器请求该资源时必须使用的协议,它与下一部分之间由 :// 这一字符组合分隔。主机部分是 example.org,标识被请求的网络服务器,在本假设字符串中它同时也是域名。2
主机之后是路径:/notes/first-page。路径表示资源在网络服务器上的位置,在本例中它暗示一个名为 notes 的目录下包含一个名为 first-page 的页面。路径之后,问号引入查询部分,本例中查询是 view=compact,这是一个键值对,向服务器提供额外参数。最后,井号引入片段部分,本例中是 intro。片段相当于资源内部的书签,为浏览器指示显示内容的具体位置。23
记录这五个标签:方案为 https,主机为 example.org,路径为 /notes/first-page,查询为 view=compact,片段为 intro。注意问号始终标志查询的开始,井号始终标志片段的开始。这两个分隔符是初次阅读URL时最容易混淆的部分,在前几次练习中明确标注它们有助于建立可靠的习惯。2
保持主机不变,对比不同路径和查询
现在保持主机部分 example.org 不变,假设同一项目还有另外两个地址:https://example.org/notes/second-page?view=full 和 https://example.org/gallery?sort=date。第一个地址的路径变为 /notes/second-page,查询变为 view=full;第二个地址的路径是 /gallery,查询是 sort=date,且都不包含片段。将三个字符串并排对比,可以看到主机完全相同,而路径、查询和片段各自独立变化。
这个观察对清单有用,因为它告诉你当页面名称变化时该更新字符串的哪一部分,当显示选项变化时又该更新哪一部分。如果只是 view 参数从 compact 切换为 full,你知道路径和主机不变,只需编辑查询部分。如果页面本身从 notes 移到了 gallery,路径变了但查询可能保留也可能消失。这里你是在阅读字符串的结构,而不是对服务器实际行为做任何推断。
一个实用提醒:把这些字符串复制到文档中时,保留问号、等号、与号(如有)和井号等所有字符。缺少一个问号或误加一个空格都可能让有效地址变成无法使用的地址。这是交接中常见的错误来源,粘贴前目视检查一遍不花任何成本。
给假设项目做一张地址说明卡
记录项目中每个页面的简短说明卡。对于本假设示例,说明卡包含四个字段:你自己选择的页面名称、完整URL、各部分标签列表,以及一行关于该页面用途的备注。例如页面名称可以写“笔记首页,紧凑视图”,用途备注可以写“笔记功能的草稿着陆区”。这些字段是你自己的组织选择,没有外部标准要求必须使用这种格式。
说明卡的价值在你需要把链接交给别人或几周后自己回来查看时变得明显。比起直接粘贴一段原始字符串然后期望对方能自行解读,你在地址旁边提供了上下文。如果项目增长到十个或二十个页面,统一的卡片格式让你可以快速浏览列表找到所需条目,而不必逐字符重新阅读每条URL。
决定把这些说明卡存放在哪里。纯文本文件、电子表格或共享文档都可以。重要的是完整URL和各部分标签在同一处,阅读说明卡的人不必在工具之间切换。如果之后你给一个原本没有片段的页面添加了片段,同时更新说明卡以保持记录准确。
用手工复制与逐项标记核对说明卡
在认为说明卡完成之前,用手工方式验证一遍。这一步能捕捉到从一个工具粘贴到另一个工具时容易遗漏的拼写错误和缺失的分隔符。
这个检查刻意保持低技术。你不是在测试页面是否能加载,而是在确认你记录的字符串与你打算记录的内容一致。如果项目最终上线,届时可以回到说明卡在浏览器中测试。
如果任何标签不匹配,立即更正说明卡并记下哪里出了错。随着时间推移,这会建立起你对所记录地址作为可靠参考的信心。
步骤 1
从说明卡中把完整URL逐字符手动输入到一行空白文本中,而不是粘贴。这迫使你注意到每一个符号。
步骤 2
在 :// 之前画一条竖线标记方案的结尾,在主机之后的第一个单斜杠之前画线标记路径的开始,在问号之前画线标记查询的开始,在井号之前画线标记片段的开始。
步骤 3
将每个标注段落与说明卡上的字段逐一比对。确认方案、主机、路径、查询和片段全部精确匹配,包括大小写和标点。
步骤 4
对页面名称和用途备注重复同样的过程,确保它们在任何近期变更之后仍然准确描述了该页面。
保留这份说明供以后写作或沟通使用
说明卡核对完成后,把它们存放在下次需要时仍然可以访问的位置。个人项目放在项目文件夹中的一个文本文件就够了;团队项目可以用共享文档或消息工具中的专用频道。目标是任何需要地址的人不必直接来问你就能找到它。
当你在文档、博客文章或邮件中引用这些页面时,从说明卡复制完整URL而不是凭记忆重新输入。这个小习惯能防止最常见的交接错误:遗漏片段、交换查询参数,或路径片段已改名但未同步更新。你的说明卡成为该字符串的唯一事实来源。
最后,定期审视你的记录选择。如果发现某些字段一直没人用,简化格式;如果发现协作者总是询问你没有包含的信息,就增加一个字段。清单服务于你的工作流,而不是反过来。经过几个项目的实践,你会发展出一种在完整性与速度之间取得平衡的个人格式,而本文的假设练习为这种迭代提供了起点。
常见问题
交接时记录URL需要包含片段吗?
如果链接的目的是指向页面内的某个特定位置,就应当包含片段。如果你只需要页面本身,可以省略片段,并在说明卡上注明这一决定,让协作者知道这是有意为之。2
URL中查询和片段有什么区别?
查询由问号引入,向网络服务器提供额外参数。片段由井号引入,是资源内部的书签,告诉浏览器滚动或聚焦到哪里;片段不会随请求一起发送给服务器。2
清单中可以只写域名而不写完整URL吗?
域名标识的是服务器而不是具体页面。对于指向单独页面的交接清单,应记录完整URL。你也可以另外记下域名作为背景信息,但让某人到达确切资源的是完整地址。21
What is a Domain Name? - Learn web development | MDN. 采集日期:2026-11-01. ↩︎ ↩︎
What is a URL? - Learn web development | MDN. 采集日期:2026-11-01. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
URL - Wikipedia. 采集日期:2026-11-01. ↩︎