当你第一次准备一个小型网站时，最早遇到的实际任务之一就是弄清楚每个页面的地址由哪些部分组成。一个完整的网页地址包含若干不同的片段，如果记录含糊或混淆各部分，就会导致链接失效和沟通误差。本文通过一个假设地址逐一标注各组成部分，并演示如何建立一份可复用的交接清单。
域名与完整URL分别回答什么问题
假设你正在规划一个小型个人项目网站，协作者问你「笔记页面放在哪里」。你可能会回答一个域名，比如 example.org，但这只告诉对方哪台服务器承载了这个站点。域名是互联网基础设施的关键组成部分，它为互联网上任何可用的网络服务器提供了一个人类可读的地址，解决了数字IP地址难以记忆且可能随时间变化的问题。域名标识的是机器本身，而不是机器上的某个特定页面。1
完整URL回答的是一个更具体的问题：你指向的是该服务器上的哪一个确切资源。URL是互联网上唯一资源的地址，也是浏览器用来获取已发布资源（如HTML页面、图片、文档等）的关键机制之一。域名把范围缩小到一台服务器，而URL的其余部分把范围缩小到该服务器上的某个特定文件或端点。理解这一区别是建立任何链接交接清单的起点。2
在实际操作中，当你把一个页面链接交给设计师、写作者或未来的自己时，仅靠域名是不够的。你需要能够定位到具体页面的完整地址。这就是为什么一份有用的清单不仅记录站点名称，还要记录完整URL，并将其拆分为各个组成部分，让阅读记录的人能理解每一段的作用。
在本例中标出地址的各个组成部分
本练习使用以下假设地址：https://example.org/notes/first-page?view=compact#intro。这个地址纯粹为了拆解URL字符串而构造，并不声称该页面真实存在或已上线。明确这一前提后，我们来逐段标注。方案（scheme）是 https，它指示浏览器请求资源时必须使用的协议。对于网站而言，协议通常是HTTPS或其未加密版本HTTP。2
本例中的域名是 example.org。域名由圆点分隔，从右向左阅读，每一部分提供关于整个域名的特定信息。这里顶级域名是 .org，标签是 example，两者合在一起标识了被请求的网络服务器。路径是 /notes/first-page，表示资源在该服务器上的位置。在早期网络中，这样的路径代表服务器上的物理文件位置，但现在它主要是由网络服务器处理的抽象概念，没有对应的物理实体。12
路径之后是查询字符串，由问号引导：?view=compact。参数是提供给网络服务器的额外键值对，服务器可以利用它们在返回资源之前进行额外处理。最后，片段标识符由井号引导：#intro。锚点代表资源内部的一种「书签」，为浏览器提供显示该书签位置内容的指引。值得注意的是，井号之后的部分不会随请求发送到服务器。因此问号标志着查询的开始，井号标志着片段的开始。2
保持主机不变，对比不同路径和查询
现在保持主机部分 example.org 完全不变，设想两个变体。第一个是 https://example.org/notes/second-page?view=compact，第二个是 https://example.org/notes/first-page?view=full#intro。在第一个变体中，只有路径从 /notes/first-page 变为 /notes/second-page，查询和片段保持不变或缺失。在第二个变体中，路径完全相同，但查询值从 compact 变为 full，片段保留。尽管域名未变，由于至少一个组成部分不同，它们就是不同的URL。2
观察这些变体有助于从记录角度厘清字符串各部分分别控制什么。路径段决定请求的是哪个资源，查询字符串提供服务器可能使用的额外参数，片段指向返回资源内部的一个位置。当你在清单上写下这些内容时，注明哪部分发生了变化、哪部分保持不变，就能毫无歧义地向他人传达差异。
需要强调的是，我们只是在描述字符串各组成部分按照URL结构所代表的含义，并没有对任何特定服务器实际如何处理这些请求作出断言。因为每台网络服务器对参数有自己的规则，要确认某台服务器是否处理特定参数，唯一可靠的方式是询问该服务器的所有者。就交接清单而言，准确记录字符串及其标注后的各部分已经足够。2
为假设项目制作一张地址说明卡
为你的假设项目中的每个页面记录一张简短的说明卡。一张有用的卡片包含四个字段：用通俗语言写的页面用途、完整URL、各组成部分的标注拆解，以及关于为何选择此地址的备注。以本例来说，用途可以写成「以紧凑视图显示的第一篇笔记页面，锚定到引言部分」。完整URL是 https://example.org/notes/first-page?view=compact#intro。标注拆解列出方案、域名、路径、查询和片段各自的值。备注字段可以记录决策原因，例如路径为何使用连字符，或查询参数为何命名为 view。
用通俗语言写出用途在交接时有特定作用。如果协作者只看到原始URL，可能无法立即理解页面的功能或某个查询参数为何存在。一句用途说明就能填补这个空白。保持语言简洁，避免非技术队友可能不认识的术语。目标是让任何阅读卡片的人都能找到页面并理解它在项目中的角色，无需追问。
对于只有少数几个页面的小型项目，一个纯文本文件或文档中的简单表格就足够了。在这个阶段不需要专门的软件。重要的是保持一致性：每张卡片使用相同的字段顺序，这样快速浏览多条记录时就很方便。如果项目增长，可以之后将卡片迁移到电子表格或维基，但每条记录的结构保持不变。
用手工复制与逐项标记核对说明卡
检查每张卡片是否与实际地址字符串一致，然后再分享给任何人。从浏览器地址栏或项目文件中复制完整URL，粘贴到卡片条目正下方的一行空白处。然后从左到右逐字符确认，卡片上的方案、域名、路径、查询和片段是否与粘贴的字符串完全吻合。路径中少一个斜杠或字母顺序颠倒，都可能指向完全不同的资源。
在每张卡片完成核对后，底部写一条简短的验证备注。类似「已于写作当日对照地址栏核实」这样简单的一句话就足以提醒未来的自己，这条记录在特定时刻经过了确认。如果项目仍在进行中且地址可能变化，加上日期以便知道上次核实是什么时候。这个习惯花费的时间很少，但能防止交出过时地址这一常见错误。
如果在核对过程中发现不一致，立即修正卡片，而不是留一条「稍后修复」的备注。清单的全部意义在于交接时刻提供可靠参考。一张带有已知错误却打算以后修复的卡片比没有卡片更糟，因为协作者会信任书面记录并按照错误地址操作。把每次核对当作卡片进入共享项目文档前的最终质量关口。
步骤 1
从你信任的来源（如浏览器地址栏或项目配置文件）复制完整URL，粘贴到卡片条目下方的空白对比行中。
步骤 2
从左到右阅读粘贴的字符串，在边距或单独一列中标注方案、域名、路径、查询和片段。
步骤 3
将每个标注段与说明卡上对应的字段逐一比较，标记任何差异。
步骤 4
修正卡片上的任何不一致，然后在条目底部写上简短的验证备注和日期。
保留这份说明供以后使用
卡片写好并核实之后，把它们存放在相关人员能够访问的地方。对于个人项目，可以是与站点文件同一文件夹中的一个文本文件；对于小团队，可以是共享文档或项目维基中的一个页面。格式不如习惯重要——关键是每当地址变化时同步更新卡片。如果你重命名了页面或调整了查询参数，当天就更新对应的卡片，使记录永远不落后于项目的实际状态。
当项目进展到需要向外部协作者、设计师或内容写作者交接链接时，这些卡片就是现成的参考。不必翻找浏览器历史或请队友重新发送链接，只需打开清单并复制已核实的地址。这减少了来回沟通，也降低了有人使用过时或拼写错误的URL的可能性。你花在制作和核实卡片上的时间，会在第一次交接顺利完成且无需澄清问题时得到回报。
随着时间推移，你可能会发现自己的记录选择有所演变。也许你会增加一列记录页面最后修改日期，或者开始按站点分区对卡片分组。这些是个人组织决策，没有唯一正确的格式。重要的是记录保持准确、结构一致、对目标读者易于阅读。一份只有你自己在六个月后才能看懂的清单已经失去了意义，因此定期问自己：一个新加入的队友能否拿起这份文档就找到所需内容，而无需向人求助。
常见问题
交接时记录页面地址需要包含片段标识符吗？
取决于接收者是否需要直接定位到页面的特定部分。片段指向资源内部的书签，且不会随请求发送到服务器。如果协作者只需要到达该页面，不含片段的地址就够了；如果需要立即看到某个特定部分，就应当包含片段。2
查询字符串是页面身份的一部分还是只是可选的显示设置？
从URL结构角度看，查询字符串是完整地址的一部分，不同的查询值会产生不同的URL。然而，服务器如何处理这些参数各有不同，每台网络服务器有自己的规则。就清单而言，最稳妥的做法是将查询作为地址的一部分记录，并用通俗语言在卡片上注明其用途。2
告诉别人页面位置时可以只写域名而不写完整URL吗？
域名标识的是服务器而非其上的特定页面。如果你的站点只有一个页面，日常对话中只说域名或许够用。但对于任何包含多个页面的项目，始终应提供完整URL，让接收者无需猜测路径就能到达确切的资源。12