在发布网站之前，你需要理解域名和完整URL之间的区别。本文用一个假设地址来展示网站地址各部分的作用，帮助你阅读、规划和记录自己项目的地址。
各部分分别回答什么问题
假设你正在规划一个小型个人项目，你写下了一个假设地址：https://example.org/notes/first-page?view=compact#intro。这个地址并不指向一个真实存在的页面，它是一个构造出来的字符串，我们只用它来练习阅读网站地址的结构。在拆解之前，先了解这个字符串在不同层面回答的两个不同问题会有帮助。
域名回答的问题是：我应该联系互联网上的哪台服务器？域名是互联网基础设施的关键组成部分，因为它们为互联网上任何可用的Web服务器提供了人类可读的地址。计算机通过数字IP地址进行通信，但人们觉得这些序列很难记住，而且它们可能随时间变化。像example.org这样的域名为你想要访问的机器提供了一个稳定、可读的标签。1
完整URL回答的是一个更具体的问题：我想要那台服务器上的哪个具体资源，以及应该如何请求它？URL是互联网上唯一资源的地址，是浏览器用来检索已发布资源（如HTML页面、图片和样式表）的关键机制之一。所以域名带你到了正确的建筑，而URL的其余部分告诉你该进哪个房间、看哪个书架。2
逐段阅读示例地址
现在来标注假设字符串中每个可见的部分。第一段https是协议方案，它指示浏览器必须使用什么协议来请求资源。对于网站来说，通常是HTTPS或其未加密的前身HTTP。下一段example.org是授权部分，包含域名并告诉浏览器要联系哪台Web服务器。在我们的例子中没有端口号，这意味着浏览器将使用HTTPS的标准端口。2
授权部分之后是路径：/notes/first-page。路径指向该服务器上的一个具体资源。在早期互联网中，这样的路径代表服务器上的一个物理文件位置，但如今它大多是Web服务器处理的抽象概念，没有对应的物理实体。路径之后，问号引出查询字符串：view=compact。参数是提供给Web服务器的额外键值对，服务器可以用它们在返回资源之前做额外处理。最后，井号引出片段：intro。锚点代表资源本身内部的一种书签，为浏览器提供指示，让它显示位于该书签位置的内容。2
两个标点符号值得特别注意，因为它们控制着各部分之间的边界。问号表示其后的所有内容都属于查询字符串，而不是路径。井号表示其后的所有内容都是片段标识符，片段标识符不会随请求发送到服务器。如果放错了其中任何一个符号，浏览器对字符串的解读就会与你的意图不同。对于我们的假设地址，完整拆解如下：协议方案为https，授权部分为example.org，路径为/notes/first-page，查询为view=compact，片段为intro。2
保持主机不变，对比不同变化
现在保持协议方案和授权部分完全不变，只改变路径。设想第二个假设地址：https://example.org/notes/second-page?view=compact#intro。被联系的服务器相同，查询和片段也相同。唯一的区别是浏览器在请求该服务器上的不同资源。这说明路径是URL中区分同一主机上不同页面或文件的部分。
接下来，保持路径不变，只改变查询。设想 https://example.org/notes/first-page?view=full#intro。服务器、资源和片段都没有变化，只有参数值不同。这意味着请求的是同一个资源，但附带了不同的指令。服务器实际如何处理该指令完全取决于它的配置方式。仅从URL字符串本身，我们无法推断服务器会接受、忽略还是拒绝某个参数。
最后，完全去掉片段：https://example.org/notes/first-page?view=compact。服务器收到的请求与之前相同，因为片段不会发送到服务器。唯一的实际区别是浏览器不会尝试滚动到返回文档中的书签位置。这个观察强化了一条有用的规则：对片段的修改只影响浏览器在接收到资源后显示什么，不影响服务器返回什么。
制作地址说明卡
记录你计划使用的每个项目地址的说明卡。说明卡不需要很复杂，一个纯文本笔记或电子表格中的一行就够了。目的是在一个地方集中记录这个地址的用途、完整字符串的样子，以及各部分在你的项目语境中代表什么。
对于我们的假设项目，说明卡可以这样写。用途：个人笔记板块的着陆页。完整地址：https://example.org/notes/first-page?view=compact#intro。协议方案：https，表示连接应加密。授权部分：example.org，项目主机的域名。路径：/notes/first-page，指向笔记目录中的第一个页面。查询：view=compact，一个显示偏好参数。片段：intro，指向该页面引言部分的书签。
同时记录每个选择背后的理由。例如，你可以注明选择路径/notes/first-page是因为你想为将来的页面（如/notes/second-page）建立一个可预测的命名模式。你可以注明查询参数是可选的，只影响显示方式。这些笔记在你或协作者以后需要理解为什么选择了某个特定地址时，会非常有价值，而不必靠猜测。
手工核对你的说明卡
在将说明卡用于文档或沟通之前，对照实际字符串进行核对。以下步骤是基于日常仔细实践的作者建议，不是任何外部规范的要求。
检查标点边界是否与你的标注一致。确认问号出现在你预期查询开始的确切位置，井号出现在你预期片段开始的确切位置。符号放错位置是手写文档中最常见的地址错误来源之一。
检查独立重新输入的地址副本，逐字符与说明卡对比。不要从原始来源粘贴，而是手动重新输入，以避免无意识的纠正。如果两份一致，说明卡就是自洽的。如果有差异，你就发现了一个转录错误，否则它会在以后造成混淆。这个简单的重复步骤能捕捉到自己在阅读自己写的字符串时容易忽略的拼写错误。
步骤 1
将完整地址字符串从说明卡复制到一个空白文本区域。不要从原始来源粘贴，手动重新输入，以避免无意识的纠正。
步骤 2
在重新输入的副本中标注每个段落：标记协议方案在哪里结束、授权部分在哪里结束、路径在哪里结束、查询从哪里开始、片段从哪里开始。
步骤 3
将你的标注与说明卡对比。如果每个边界都匹配，说明卡已核实。如果任何边界不同，修正说明卡并重复检查。
保留记录供以后使用
说明卡核实之后，把它存放在你以后确实会再次查看的地方。项目README文件、共享笔记或简单的电子表格行都可以。格式不如保持记录及时更新的习惯重要。如果以后改变了路径结构或添加了新参数，同时更新说明卡，以免它与实际情况脱节。
这份记录服务于两类读者。第一类是未来的你自己。当你在数周或数月后回到一个项目时，一张清晰的地址说明卡能让你免于重新推导URL各部分在语境中的含义。第二类是你可能寻求帮助的任何协作者或助手。分享一份标注好的拆解比粘贴一个原始字符串然后请别人猜测你的意图要高效得多。
你不需要记录地址的每一种可能变化。把重点放在对项目公开入口、内部导航或任何参数会改变可见结果的地方有影响的地址上。目标是一个小而可靠的参考，你可以快速查阅，而不是服务器理论上能处理的每个字符串的详尽目录。
常见问题
URL的片段部分会发送到Web服务器吗？
不会。片段标识符，即井号后面的部分，不会随请求发送到服务器。它仅由浏览器用来定位已获取资源内部的位置。2
修改查询字符串会影响加载哪个页面吗？
查询字符串向服务器提供额外参数，但这些参数是否改变返回的内容完全取决于服务器的配置方式。路径才是标识资源的部分；查询给出的是服务器可能执行也可能不执行的附加指令。2
域名和完整URL有什么区别？
域名标识要联系哪台服务器。完整URL包含域名加上协议方案、路径、查询和片段等额外部分，它标识该服务器上的一个具体资源以及如何请求它。12