准备一个小型网站项目时，你迟早需要把页面地址告诉协作者、设计师或未来的自己。一份简短的清单，把每个页面的名称、完整地址和用途备注放在一起，能避免日后产生混乱。本文用一个明确标注为假设的示例地址，走一遍这个记录过程。
一个需要交接记录的假设项目
假设你正在规划一个小型个人项目站点。你已经在纸上画了几个页面的草图，现在需要把规划好的结构分享给一位帮忙做设计的朋友。与其发送零散的消息，你决定制作一份简单的交接文档，按名称和完整地址列出每个页面。为了这次练习，我们使用一个假设地址：https://example.org/notes/first-page?view=compact#intro。这个地址不指向任何真实页面，也没有在任何地方发布过。它仅仅是一段供我们拆解、标注和记录的字符串。
完整地址在交接中之所以重要，是因为单凭页面名称会产生歧义。一位协作者看到「第一个页面」这个标签，无法知道它属于哪个站点、位于哪个目录、是否携带额外参数。完整的URL消除了这种歧义，因为正如MDN所解释的，URL是互联网上唯一资源的地址，也是浏览器用来获取已发布资源的关键机制之一。1
把地址和人类可读的页面名称并排记录，等于同时保留了两个参照点：浏览器需要的技术字符串，以及人需要的通俗标签。清单方式把两者绑在一起，这样当项目增长到两三个页面以上时，任何一项都不会丢失。
标注示例地址的各个部分
把完整字符串 https://example.org/notes/first-page?view=compact#intro 写在一行空白处，然后逐段标记。开头的 https 是协议方案（scheme），表示浏览器请求资源时必须使用的协议。example.org 这一段是域名（domain），标识被请求的是哪台网络服务器。/notes/first-page 是路径（path），指向该服务器上资源的位置。问号引出查询字符串 view=compact，向服务器提供额外参数。井号引出片段 intro，它相当于资源内部的一个书签。1
MDN将协议方案描述为指示请求所用协议的部分，将域名描述为标识被请求的网络服务器的部分，将路径描述为资源在该服务器上的位置。参数部分被描述为提供给网络服务器的额外键值对，锚点或片段被描述为资源内部的书签，为浏览器指示显示特定位置内容的方向。这些定义为你的说明卡提供了稳定的标签用语。1
标注各部分时，在整份清单中使用一致的术语。如果在一处把 example.org 称为「域名」，就不要在另一处不加说明地改称「主机」或「站点名」。一致的标签让文档对任何后来接手的人都是可快速浏览的。
保持主机不变，对比不同变体
现在保持 example.org 不变，想象另外两个规划中的页面。一个可能是 https://example.org/notes/second-page?view=full，另一个可能是 https://example.org/about/team。三者共享相同的协议方案和域名，但路径不同，只有前两个携带查询字符串。片段是否出现取决于页面中是否包含值得直接链接的书签位置。
这个对比说明了为什么记录完整字符串比只记域名更重要。同一域名下的两个页面可以指向完全不同的资源，因为它们的路径不同。查询字符串又增加了一层区分：view=compact 和 view=full 是不同的参数值，服务器可能以不同方式处理它们，不过正如MDN所指出的，确认特定服务器如何处理参数的唯一可靠方式是询问服务器所有者。1
对你的交接清单而言，这意味着即使多个页面共享同一域名，每一行仍应记录完整地址。不要用「同上」来缩写域名。在每一行重复完整字符串只需多花几秒钟打字，却能彻底消除误读路径归属哪个主机的可能。
制作一张地址说明卡
为每个规划中的页面记录以下字段：简短的通俗页面名称、完整绝对URL、协议方案、域名、路径、查询参数（如有）、片段（如有），以及一句关于页面用途的备注。对于我们的假设示例，说明卡的内容为：页面名称「第一个笔记页」，完整地址 https://example.org/notes/first-page?view=compact#intro，协议方案 https，域名 example.org，路径 /notes/first-page，查询 view=compact，片段 intro，用途「以紧凑阅读视图显示第一条笔记条目，锚定到引言部分」。
用途备注是你自己的编辑性补充。它不来自URL字符串本身，而来自你对该页面预期功能的理解。把它和技术部分放在同一张卡上，意味着未来的读者能同时看到地址和它存在的原因，不必翻找其他文档。
如果你的项目包含页面之间的内部链接，请注明哪些页面链接到哪些页面。MDN解释说，内部链接连接属于同一网站的网页，没有内部链接就不存在多页面网站。把这些关系记录在说明卡上，能帮助协作者一眼看懂导航流向。2
步骤 1
列出所有规划中的页面名称，使用通俗语言。
步骤 2
在每个名称旁边写出完整的绝对URL，从你的规划笔记中逐字符抄写。
步骤 3
把每个URL拆分为协议方案、域名、路径、查询和片段，在说明卡上逐一标注。1
步骤 4
添加一句用途备注，并在适用时注明哪些其他页面链接到本页或从本页链出。2
通过手工抄写与逐项标注核对说明卡
检查完成的说明卡时，把完整URL抄写到一个新的文本文件中，不使用粘贴功能。逐字符手工输入，然后把输入版本与原始记录对比。这个缓慢的过程能发现字符颠倒、缺少斜杠或意外空格等快速目视扫描容易遗漏的问题。
重新输入之后，从头开始再次标注每个片段。标出协议方案在哪里结束、域名从哪里开始和结束、路径从哪里起始、查询和片段的分隔符位于何处。如果你的标注与原始说明卡一致，说明记录是统一的。如果不一致，你就找到了原始记录不清晰或包含错误的地方。
在分享文档之前，对清单上的每一行都重复这个核对过程。对于一个三页项目来说，所需精力很小；当列表增长到十个或更多页面时，这一步就变得必不可少，因为一个错误字符就可能把协作者引向错误的资源或产生令人困惑的报错。
步骤 1
打开一个空白文本文件，从说明卡上重新输入完整URL，不复制粘贴。
步骤 2
在重新输入的版本中独立标注协议方案、域名、路径、查询和片段。1
步骤 3
将你独立做出的标注与原始说明卡对比，修正任何不一致之处。
保留记录供日后写作与沟通使用
把完成的清单存放在你日后会回顾的位置：项目文件夹、共享文档或你日常使用的笔记工具。说明卡的价值在于日后查阅，而不在于创建一次。当你撰写内容、更新导航或让新的帮手加入时，说明卡提供一个统一的参考，回答每个页面叫什么、在哪里、为什么存在。
如果项目演进，某个页面移动到了新路径或获得了新的查询参数，立即更新说明卡。过时的记录比没有记录更糟，因为它会主动误导。把说明卡当作反映项目当前规划状态的活文档，而不是项目启动时的快照。
维护这类记录的习惯可以自然扩展。无论你的项目停留在三个页面还是增长到三十个，名称、完整地址、标注部分和用途备注这组结构都让每条记录自成一体。你可以把文档交给任何人而不需要额外的口头解释，这正是任何交接清单的实际目标。
常见问题
如果页面没有书签片段，说明卡上还需要填写片段字段吗？
不需要。片段是可选的。如果页面不包含你想直接链接到的特定部分，可以把该字段留空或写「无」。片段只在需要指向页面内某个特定位置时才有意义。1
清单上应该记录相对URL还是绝对URL？
记录绝对URL。相对URL依赖当前文档的上下文来补全协议方案和域名等缺失部分。绝对URL是自包含的，任何阅读说明卡的人都能理解完整地址，而不必知道自己当前在哪个页面上。1
如果不确定服务器如何处理我记录的查询参数，该怎么办？
按地址字符串中实际出现的样子记录参数，并添加一条备注说明其行为尚未确认。MDN指出，每台网络服务器对参数有自己的规则，确认特定服务器是否处理参数的唯一可靠方式是询问服务器所有者。你的说明卡记录的是地址本身；确认服务器行为是另一个步骤。1