当你第一次准备上线一个网站时，会遇到两个相关但不同的概念：域名和完整URL。混淆二者可能导致与协作者沟通出错，或在记录项目信息时产生偏差。本文用一个假设地址来展示这些部分如何组合在一起。
域名与完整URL分别回答什么问题
假设你正在搭建一个小型个人项目，有人问你：“你的网站地址是什么？”你可以只回答一个域名，比如example.org，也可以给出一串更长的地址，比如https://example.org/notes/first-page?view=compact#intro。两种回答都指向同一个站点，但它们回答的是不同的问题。域名标识的是主机，即你的内容所在的那台机器或服务；完整URL标识的是该主机上的某一个具体资源。理解这个区别，能帮助你在讨论时清楚地表明自己说的是整个站点还是其中某一个页面。12
域名之所以存在，是因为人们很难记住数字形式的IP地址并将其与用途联系起来。MDN指出，域名是互联网基础设施的关键组成部分，为任何可用的网络服务器提供人类可读的地址，解决了IP地址难以记忆且可能随时间变化的问题。而URL则是互联网上唯一资源的地址，是浏览器用来获取已发布资源（如HTML页面、CSS文档和图片）的关键机制之一。简而言之，域名回答的是“哪台服务器？”，完整URL回答的是“那台服务器上的哪个具体资源？”12
本文后续将围绕一个假设地址展开：https://example.org/notes/first-page?view=compact#intro。这个地址纯粹用于拆解字符串的练习，不声称该页面真实存在或已经上线。目标是练习识别每个组成部分，这样当你遇到自己项目中的真实地址时，能够有把握地读懂它们。
在本例中标出每个组成部分
从左到右逐段看这个假设地址。第一部分https是协议方案。根据MDN的说明，协议方案表示浏览器必须使用的协议来获取资源，对于网站来说通常是HTTPS或HTTP。接下来是example.org，这是权限部分中的主机名，也就是标识被请求的网络服务器的域名。MDN指出，域名指示了被请求的是哪台网络服务器，并且域名为该服务器提供了人类可读的地址。12
主机之后是路径：/notes/first-page。路径表示资源在网络服务器上的位置。MDN将其描述为资源的路径，并指出在早期Web中它代表服务器上的物理文件位置，而现在主要是由网络服务器处理的抽象概念。路径之后，问号引导查询字符串：view=compact。MDN解释说，参数是提供给网络服务器的额外键值对，当有多个参数时用与号分隔。最后，井号引导片段标识符：intro。MDN说明锚点代表资源内部的一种书签，为浏览器提供方向以显示该书签位置的内容，并且片段标识符在请求中永远不会发送到服务器。2
总结标注结果：https是协议方案，example.org是主机，/notes/first-page是路径，问号表示查询的开始，view=compact是查询参数，井号表示片段的开始，本例中片段为intro。记住这些标签后，你在与协作者讨论某个具体地址或排查加载问题时就会容易得多。2
保持主机不变，对比不同路径和查询
现在保持主机部分example.org不变，只改变路径。比较https://example.org/notes/second-page和https://example.org/about/contact。两种情况下浏览器都会向同一台服务器请求资源，但路径部分告诉服务器要找的是哪个资源。主机后面的字符串只是关于去哪里查找的不同指示。我们不对服务器实际返回什么做任何推断，只是观察字符串本身的差异。
接下来保持路径不变，只改变查询字符串。比较https://example.org/notes/first-page?view=compact与https://example.org/notes/first-page?view=full。主机和路径完全相同，只有分配给view参数的值发生了变化。从字符串阅读的角度看，这是两个指向同一路径但携带不同参数的不同URL。服务器是否真的对它们做不同处理，完全取决于那台服务器的配置方式，这不是我们从地址字符串本身能确定的。
你也可以完全去掉片段。地址https://example.org/notes/first-page?view=compact是一个不含任何井号或片段部分的有效URL。加上#intro只是告诉浏览器在获取的资源中滚动到某个特定位置。去掉它不会改变请求的资源本身，只是改变了浏览器是否收到关于在哪里定位视图的指示。认识到这些区别有助于你在并排比较两个地址时精确描述到底哪里变了。
给假设项目做一张地址说明卡
记录一张简短的说明卡来描述你的假设项目。卡片应包含三项内容：用一句话说明地址的用途、完整的地址字符串、以及各部分的标注拆解。对于我们的例子，用途可以写成：“笔记首页的紧凑视图，滚动到引言部分。”完整地址是https://example.org/notes/first-page?view=compact#intro。拆解列出：协议方案为https，主机为example.org，路径为/notes/first-page，查询为view=compact，片段为intro。
写这张卡片会迫使你面对自己对地址理解中的任何模糊之处。如果你无法清楚地陈述用途，可能意味着你还不确定这个页面应该做什么。如果你无法标注某个部分，那就是需要回顾定义的信号。卡片不是技术要求，而是一个个人参考工具，能让以后关于你站点的对话更加精确。
你可以把这张卡片保存在纯文本文件、笔记应用甚至手写的卡片上。格式不重要，只要三项内容齐全且清晰即可。有人喜欢用表格，列出部分名称、值和简短说明；有人喜欢写成一段自然流畅的文字。选择你最可能在需要向别人解释地址时回头查看的那种格式。
用手工复制与逐项标记核对说明卡
检查你的说明卡是否与原始地址字符串一致，方法是把完整URL复制到一个空白行，然后用不同的符号或颜色标记每个边界。例如，在https后面画一条竖线，在example.org后面再画一条，在/notes/first-page后面再画一条，在?view=compact后面再画一条，并注意#intro是最后一个片段。这种手工标记练习能发现常见错误，比如忘记引导查询的问号，或者把路径中的斜杠与分隔协议方案和权限部分的冒号双斜杠搞混。
把每个标注部分单独写在一行上，逐行排列，然后将你的列表与上一节创建的卡片进行对比。如果有任何部分缺失或位置错误，在分享给别人之前先修正卡片。特别注意查询字符串是否以问号开头、片段是否以井号开头，因为这两个分隔符在快速阅读时很容易被忽略。
每次修改地址后都重复一次这个核对过程。即使是很小的改动，比如添加第二个查询参数或重命名一个路径段，都可能使你之前标记的边界发生移动。把核对变成习惯意味着你很少会给协作者发送包含错误的描述，同时你也会对自己阅读其他网站上陌生地址的能力越来越有信心。
保留这份说明供以后使用
把核对过的说明卡存放在项目过程中你自然会看到的地方。如果你维护项目的README或规划文档，就把卡片放在那里。如果你与设计师或开发者沟通，可以在第一条消息中粘贴相关部分，让双方基于对地址结构的相同理解来工作。制作这张卡片几乎不花时间，但能在以后省去反复澄清的来回。
随着项目发展，你可能会积累多个地址：首页一个、博客区一个、设置页一个，等等。每一个都可以按照同样的三项格式制作自己的卡片。随着时间推移，这组卡片会成为一份快速参考，帮助你发现命名中的规律和不一致之处，也能向新加入的协作者解释站点结构，而不必每次从头推导。
记录应该多详细取决于项目的规模以及你预计多久需要和别人讨论一次地址。对于单页个人站点，一张卡片可能就足够了。对于多板块的项目，按板块分组的一小表格能让所有内容保持易于查找。重要的是你拥有一份一致且诚实的记录，说明字符串每个部分的含义，这样下次有人问“你的网站地址是什么”时，你可以根据情况需要给出任何详细程度的回答。
常见问题
域名和URL是同一个东西吗？
不是。域名标识的是主机服务器，而URL是该服务器上某个具体资源的完整地址。域名是URL中的一个组成部分。12
URL中的片段部分会发送到服务器吗？
不会。根据MDN的说明，片段标识符（井号后面的部分）在请求中永远不会发送到服务器。它只由浏览器用来在已获取的资源中定位视图位置。2
只改变查询字符串会改变请求的页面吗？
路径部分标识的是资源，而查询字符串提供的是额外参数。只改变查询而保持路径不变时，从字符串阅读的角度看资源位置没有变化，但服务器是否做出不同响应取决于它自身的配置。