我想知道这两种URL之间的区别：相对URL（图片，CSS文件，JS文件等）和绝对URL .
另外，哪一个更好用？
如果它是在您的网站中使用，最好使用相对URL，如果您需要将网站移动到另一个域名或只是本地调试，您可以 .
看一下stackoverflow正在做什么（在Firefox中使用ctrl U）：
<a href="/users/recent/90691"> // Link to an internal element
在某些情况下，他们使用绝对网址：
<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">
......但这只是提高速度的最佳做法 . 在你的情况下，它看起来不像你做的那样，所以我不担心它 .
我不得不在这里不同意多数人的意见 .
我认为相对URL方案是“很好”，当你想快速启动并运行时，不要在盒子外面思考，特别是如果你的项目很少，开发人员很少（或者只是你自己） .
但是，一旦你开始处理大型，脂肪系统，你一直在切换域和协议，我相信一个更优雅的方法是有序的 .
当您从本质上比较绝对和相对URL时，Absolute获胜 . 为什么？因为它永远不会破裂 . 永远 . 绝对URL正是它所说的 . 问题在于您必须保留绝对URL .
绝对URL链接的弱方法实际上是对整个URL进行硬编码 . 这不是一个好主意，也可能是为什么人们认为它们是危险/邪恶/烦人维持的罪魁祸首 . 更好的方法是为自己编写一个易于使用的URL生成器 . 这些都很容易编写，并且可以非常强大 - 自动检测您的协议，易于配置（字面上为整个应用程序设置一次网址）等，它会自动注入您的域名 . 关于这一点的好处：您继续使用相对URL进行编码，并且在运行时，应用程序会立即将您的URL作为完整绝对值插入 . 真棒 .
看到几乎所有现代网站都使用某种动态后端，所以这个网站的最佳利益就是这样做 . 绝对URL不仅可以让您确定它们的位置指向 - 他们也可以提高SEO性能 .
我可能会补充一点，绝对URL以某种方式改变页面加载时间的论点是一个神话 . 如果你的域重量超过几个字节，那么你就不再这么做了 . https://stackoverflow.com/是25个字节，而它们用于站点导航区域的"topbar-sprite.png"文件的重量为9 kb . 这意味着与精灵文件相比，额外的URL数据是加载数据的.2％，并且该文件甚至不被视为性能损失 .
这个大而未经优化的整页背景图像更有可能减慢加载时间 .
关于为什么不应该使用相对URL的有趣帖子在这里：http://yoast.com/relative-urls-issues/
例如，亲戚可能会遇到的一个问题是，有时服务器映射（请注意大型，混乱的项目）不与文件名对齐，开发人员可能会假设相关URL不是真正 . 我今天刚看到我正在进行的一个项目，它整个页面都缩小了 .
或者，开发人员可能忘记切换指针，并且突然谷歌将整个测试环境编入索引 . 哎呀 - 重复内容（对SEO不好！） .
绝对可能是危险的，但如果使用得当并且不能破坏你的构造，它们被证明更可靠 . 看看上面的文章，它给出了为什么Wordpress url生成器超级棒的原因 .
:)
在大多数情况下，相对URL是可行的方式，它们本质上是可移植的，这意味着如果您想要提升您的网站并将其放在其他地方，它可以立即工作，从而减少可能数小时的调试 .
有一个相当不错的article on absolute vs relative URLs，检查一下 .
通常，最佳做法是使用相对URL，这样您的网站就不会绑定到当前部署的基本URL . 例如，它可以在localhost上工作，也可以在公共域上工作，无需修改 .
如果绝对URL是指包括方案（例如http / https）和主机名（例如yourdomain.com）的URL，则不会这样做（对于本地资源），因为维护和调试会很糟糕 .
假设您在代码中使用了绝对URL，如 <img src="http://yourdomain.com/images/example.png"> . 现在，当你要去的时候会发生什么：
<img src="http://yourdomain.com/images/example.png">
切换到另一个方案（例如http - > https）
切换域名（test.yourdomain.com - > yourdomain.com）
在第一个示例中，将发生的是您将收到有关页面上请求的不安全内容的警告 . 因为您的所有网址都是硬编码的，所以使用http（：//yourdomain.com/images/example.png） . 当通过http运行您的页面时，浏览器期望通过https加载所有资源以防止泄露信息 .
在第二个示例中，当您的网站从测试环境中直播时，这意味着所有资源仍然指向您的测试域而不是您的实时域 .
因此，要回答有关是使用绝对URL还是相对URL的问题：始终使用相对URL（对于本地资源） .
首先让我们看一下我们可以使用的不同URL：
http://yourdomain.com/images/example.png
//yourdomain.com/images/example.png
/images/example.png
images/example.png
在下面的示例中，我假设网站从服务器 /var/www/mywebsite 上的以下位置运行 .
/var/www/mywebsite
上述（绝对）URL尝试访问资源 /var/www/website/images/example.png . 出于上述原因，您始终希望避免这种类型的URL从您自己的网站请求资源 . 但它确实有它的位置 . 例如，如果您有一个网站 http://yourdomain.com 并且您想通过http从外部域请求资源，则应使用此方法 . 例如 . https://externalsite.com/path/to/image.png .
/var/www/website/images/example.png
http://yourdomain.com
https://externalsite.com/path/to/image.png
此URL是基于当前使用的方案的相对URL，并且在包含外部资源（图像，javascripts等）时几乎总是应该使用 .
这种类型的URL的作用是使用它所在页面的当前方案 . 这意味着您在页面 http://yourdomain.com 并且该页面上是图像标记 <img src="//yourdomain.com/images/example.png"> 图像的URL将在 http://yourdomain.com/images/example.png 中解析 .当你在页面 http**s**://yourdomain.com 上并且在该页面上是图像标签 <img src="//yourdomain.com/images/example.png"> 时，图像的URL将在 https://yourdomain.com/images/example.png 中解析 .
<img src="//yourdomain.com/images/example.png">
http**s**://yourdomain.com
https://yourdomain.com/images/example.png
这可以防止在不需要时通过https加载资源，并自动确保在需要时通过https请求资源 .
上述URL在服务器端以与先前URL相同的方式解析：
上述（绝对）URL尝试访问资源/var/www/website/images/example.png .
对于本地资源，这是引用它们的首选方式 . 这是基于您网站的文档根目录（ /var/www/mywebsite ）的相对URL . 这意味着当你有 <img src="/images/example.png"> 时，它将始终解析为 /var/www/mywebsite/images/example.png .
<img src="/images/example.png">
/var/www/mywebsite/images/example.png
如果在某些时候您决定切换域，它仍然可以工作，因为它是相对的 .
这也是一个相对URL，虽然与前一个有点不同 . 此URL与当前路径相关 . 这意味着它将根据您在站点中的位置解析到不同的路径 .
例如，当您在页面 http://yourdomain.com 并且您使用 <img src="images/example.png"> 时，它会在服务器上按照预期解析为 /var/www/mywebsite/images/example.png ，但是当您在页面 http://yourdomain.com/some/path 上并且使用完全相同的图像标记时，它会突然解析为 /var/www/mywebsite/some/path/images/example.png .
<img src="images/example.png">
http://yourdomain.com/some/path
/var/www/mywebsite/some/path/images/example.png
在请求外部资源时，您很可能希望使用相对于方案的URL（除非您要强制使用其他方案），并且在处理本地资源时，您希望使用基于文档根目录的相对URL .
示例文档：
<!DOCTYPE html> <html> <head> <title>Example</title> <link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'> <link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style> </head> <body> <img src="/images/some/localimage.png" alt=""> <script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script> </body> </html>
Safe way to write URLs that transfer across environments
what is the correct way to link image in website?
看到：http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
foo://username:password@example.com:8042/over/there/index.dtb;type=animal?name=ferret#nose \ / \________________/\_________/ \__/ \___/ \_/ \_________/ \_________/ \__/ | | | | | | | | | | userinfo hostname port | | parameter query fragment | \_______________________________/ \_____________|____|____________/ scheme | | | | | authority |path| | | | | path interpretable as filename | ___________|____________ | / \ / \ | urn:example:animal:ferret:nose interpretable as extension
一个绝对URL包括"path"部分之前的部分 - 换句话说，它包括方案（ http://foo/bar/baz 在 http://foo/bar/baz 中）和主机名（ foo 在 http://foo/bar/baz 中）（以及可选的端口，userinfo和端口） .
http://foo/bar/baz
foo
相对网址以路径开头 .
绝对的网址是绝对的：资源的位置只能在网址本身查找 . 相对URL在某种意义上是不完整的：要解决它，您需要方案和主机名，这些通常取自当前上下文 . 例如，在网页中
http://myhost/mypath/myresource1.html
你可以把这样的链接
<a href="pages/page1">click me</a>
在链接的 href 属性中，使用了相对URL，如果单击它，则必须解析它以便遵循它 . 在这种情况下，当前的上下文是
href
所以这些的模式，主机名和前导路径都被采用并预先添加到 pages/page1 ，屈服
pages/page1
http://myhost/mypath/pages/page1
如果链接是：
<a href="/pages/page1">click me</a>
（注意 / 出现在网址的开头）然后它将被解析为
/
http://myhost/pages/page1
因为前导 / 表示主机的根目录 .
在Web应用程序中，我建议对属于您的应用程序的所有资源使用相对URL . 这样，如果您更改页面的位置，一切都将继续工作 . 任何外部资源（可能是完全在您的应用程序之外的页面，也是您通过内容传送网络提供的静态内容）应始终使用绝对URL指向：如果您不这样做，则根本无法找到它们，因为它们驻留在不同的服务器上 .
假设我们正在创建一个子网站，其文件位于文件夹http://site.ru/shop中 .
Link to home page href="http://sites.ru/shop/" Link to the product page href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"
Link from home page to product page href="t-shirts/t-shirt-life-is-good/" Link from product page to home page href="../../"
虽然相对URL看起来比绝对URL短，但绝对URL更可取，因为链接可以在站点的任何页面上不加改变地使用 .
我们考虑了两种极端情况：“绝对”绝对和“绝对”相对URL . 但在这个世界上，一切都是相对的 . 这也适用于URL . 每当你说绝对URL时，你应该总是指定相对于什么 .
Link to home page href="//sites.ru/shop/" Link to product page href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"
Google建议使用此类网址 . 但是，现在通常认为http：//和https：//是不同的站点 .
即相对于域的根文件夹 .
Link to home page href="/shop/" Link to product page href="/shop/t-shirts/t-shirt-life-is-good/"
如果所有页面都在同一个域中，那么这是一个不错的选择 . 当您将站点移动到另一个域时，您不必在URL中大量替换域名 .
标签<base>指定基本URL，它会自动添加到所有相关链接和锚点 . 基本标记不会影响绝对链接 . 作为基本URL，我们将指定主页：<base href =“http://sites.ru/shop/”> .
Link to home page href="" Link to product page href="t-shirts/t-shirt-life-is-good/"
现在，您不仅可以将站点移动到任何域，还可以移动到任何子文件夹中 . 请记住，尽管URL看起来像是相对的，但实际上它们是绝对的 . 特别要注意锚点 . 要在当前页面中导航，我们必须编写href =“t-shirts / t-shirt-life-is-good /＃comments”而不是href =“＃comments” . 后者将扔在主页上 .
对于内部链接，我使用基本相对URL（5） . 对于外部链接和新闻简报，我使用绝对URL（1） .
实际上应该明确讨论三种类型 . 实际上虽然URL被抽象为在较低级别处理，但我甚至可以说开发人员可以完成整个生命而无需手动编写单个URL .
绝对URL将您的代码与协议和域绑定在一起 . 这可以通过动态URL来克服 .
<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>
Absolute Pros:
Control - 可以控制子域和协议 . 通过一个不起眼的子域进入的人将被汇入正确的子域 . 您可以根据需要在安全和非安全之间来回跳转 .
Configurable - 开发人员喜欢绝对的东西 . 使用绝对URL时，您可以设计整洁的算法 . 可以对URL进行配置，以便可以在单个配置文件中进行单个更改，从而在站点范围内更新URL .
Clairvoyance - 您可以搜索抓取您网站的人，也可以搜索一些额外的外部链接 .
根相对URL将您的代码绑定到基本URL . 这个可以使用动态网址和/或base tags来克服 .
<a href=“/index.php?q=”>.example.com/index.php?q=</a>
Root Relative Pros:
相对URL将您的代码绑定到目录结构 . 没有办法克服这一点 . 相对URL仅在文件系统中用于遍历目录或作为琐事任务的快捷方式 .
<a href=“index.php?q=”>index.php?q=</a> <link src=“../.././../css/default.css” />
Relative Cons:
CONFUSING - 那是多少个点？这是多少个文件夹？文件在哪里？为什么不工作？
MAINTENANCE - 如果文件被意外移动资源退出加载，链接会将用户发送到错误的页面，表单数据可能会被发送到错误的页面 . 如果要移动文件NEEDS，则需要更新所有要退出加载的资源以及所有不正确的链接 .
DOES NOT SCALE - 当网页变得更加复杂并且视图开始在多个页面中重复使用时，相对链接将相对于它们所包含的文件 . 如果你有一个HTML的导航片段将在每个页面上，那么亲戚将相对于许多不同的地方 . 人们在开始创建模板时首先意识到，他们需要一种管理URL的方法 .
COMPUTED - 它们由您的浏览器实现（希望根据RFC） . 见RFC3986中的第5章 .
OOPS! - 错误或拼写错误会导致蜘蛛陷阱 .
开发人员已经停止在此处讨论的意义上编写URL . 所有请求都是针对网站的索引文件，并包含查询字符串，即路径 . 该路由可以被视为一个迷你URL，告诉您的应用程序要生成的内容 .
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>"> http://dev.example.com/index.php/my:whacky:url </a>
Routes Pros:
绝对网址的所有优点 .
使用URL中的任何字符 .
更多控制（适合SEO） .
能够以算法方式生成URL . 这允许URL可配置 . 更改URL是单个文件中的单个更改 .
不需要404未找到 . 后备路由可以显示站点 Map 或错误页面 .
间接访问应用程序文件的便捷安全性 . Guard语句可以确保每个人都通过适当的渠道到达 .
MVC方法的实用性 .
大多数人会以某种方式在他们的项目中使用所有三种形式 . 关键是要了解它们并选择最适合该任务的那个 .
以URL方案和方案特定部分（ http:// ， https:// ， ftp:// 等）开头的URL是绝对URL .
http://
https://
ftp://
任何其他URL都是相对URL，并且需要一个基本URL，相对URL是从中解析的（因此依赖于），如果没有另外声明，则是使用引用的资源的URL .
请查看RFC 2396 – Appendix C以获取解析相对URL的示例 .
假设您有一个网站www.yourserver.com . 在Web文档的根目录中，您有一个图像子指南，并且您有myimage.jpg .
绝对URL定义文档的确切位置，例如：
http://www.yourserver.com/images/myimage.jpg
相对URL定义了相对于当前目录的位置，例如，假设您位于图像所在的根网站目录中：
images/myimage.jpg
（相对于该根目录）
您应该尽可能使用相对URL . 如果您将网站移至www.anotherserver.com，则必须更新指向www.yourserver.com的所有绝对URL，相关的URL将保持原样 .
对于支持相对URI解析的每个系统，相对URI和绝对URI都可以实现相同的目标：引用 . 它们可以互换使用 . 所以你可以在每种情况下做出不同的决定从技术上讲，它们提供相同的参考 .
确切地说，对于每个相对URI，已经存在绝对URI . 这就是解析相对URI的基URI . 因此，相对URI实际上是绝对URI之上的一个特性 .
这就是为什么使用相对URI可以做到更多，就像单独使用绝对URI一样 - 这对于静态网站来说尤其重要，否则与绝对URI相比，静态网站的维护难度不大 .
相对URI解析的这些积极影响也可以用于动态Web应用程序开发 . 在动态环境中，引入的不灵活绝对URI也更容易应对，因此对于一些不确定URI解析以及如何正确实现和管理它的开发人员（并不总是那么容易），通常选择使用绝对值在网站的动态部分中的URI，因为它们可以引入其他动态功能（例如，包含URI前缀的配置变量），以便解决不灵活性问题 .
那么使用绝对URI有什么好处呢？从技术上讲，没有，但我会说：相对URI更复杂，因为它们需要针对所谓的绝对基URI进行解析 . 即使分辨率严格定义多年，您也可能会遇到URI解析错误的客户端 . 由于绝对URI不需要任何解析，因此使用绝对URI不会因相对URI解析而遇到错误的客户端行为 . 那么实际风险有多高？嗯，这是非常罕见的 . 我只知道一个互联网浏览器有相对URI解析的问题 . 这不是一般情况，只是在一个非常（模糊）的情况下 .
在HTTP客户端（浏览器）旁边，对于超文本文档或代码的作者来说，它可能更复杂 . 这里绝对URI的优点是更容易测试，因为您只需将其按原样输入浏览器地址栏即可 . 但是，如果它不仅仅是您的一小时工作，那么实际了解绝对和相对URI处理通常会让您更有利，这样您就可以实际利用相对链接的好处 .
我衷心地建议将相同网址的相对URL推荐到同一网站的其他位 .
不要忘记，对HTTPS的更改 - 即使在同一站点中 - 也需要一个绝对URL .
12 回答
如果它是在您的网站中使用，最好使用相对URL，如果您需要将网站移动到另一个域名或只是本地调试，您可以 .
看一下stackoverflow正在做什么（在Firefox中使用ctrl U）：
在某些情况下，他们使用绝对网址：
......但这只是提高速度的最佳做法 . 在你的情况下，它看起来不像你做的那样，所以我不担心它 .
我不得不在这里不同意多数人的意见 .
我认为相对URL方案是“很好”，当你想快速启动并运行时，不要在盒子外面思考，特别是如果你的项目很少，开发人员很少（或者只是你自己） .
但是，一旦你开始处理大型，脂肪系统，你一直在切换域和协议，我相信一个更优雅的方法是有序的 .
当您从本质上比较绝对和相对URL时，Absolute获胜 . 为什么？因为它永远不会破裂 . 永远 . 绝对URL正是它所说的 . 问题在于您必须保留绝对URL .
绝对URL链接的弱方法实际上是对整个URL进行硬编码 . 这不是一个好主意，也可能是为什么人们认为它们是危险/邪恶/烦人维持的罪魁祸首 . 更好的方法是为自己编写一个易于使用的URL生成器 . 这些都很容易编写，并且可以非常强大 - 自动检测您的协议，易于配置（字面上为整个应用程序设置一次网址）等，它会自动注入您的域名 . 关于这一点的好处：您继续使用相对URL进行编码，并且在运行时，应用程序会立即将您的URL作为完整绝对值插入 . 真棒 .
看到几乎所有现代网站都使用某种动态后端，所以这个网站的最佳利益就是这样做 . 绝对URL不仅可以让您确定它们的位置指向 - 他们也可以提高SEO性能 .
我可能会补充一点，绝对URL以某种方式改变页面加载时间的论点是一个神话 . 如果你的域重量超过几个字节，那么你就不再这么做了 . https://stackoverflow.com/是25个字节，而它们用于站点导航区域的"topbar-sprite.png"文件的重量为9 kb . 这意味着与精灵文件相比，额外的URL数据是加载数据的.2％，并且该文件甚至不被视为性能损失 .
这个大而未经优化的整页背景图像更有可能减慢加载时间 .
关于为什么不应该使用相对URL的有趣帖子在这里：http://yoast.com/relative-urls-issues/
例如，亲戚可能会遇到的一个问题是，有时服务器映射（请注意大型，混乱的项目）不与文件名对齐，开发人员可能会假设相关URL不是真正 . 我今天刚看到我正在进行的一个项目，它整个页面都缩小了 .
或者，开发人员可能忘记切换指针，并且突然谷歌将整个测试环境编入索引 . 哎呀 - 重复内容（对SEO不好！） .
绝对可能是危险的，但如果使用得当并且不能破坏你的构造，它们被证明更可靠 . 看看上面的文章，它给出了为什么Wordpress url生成器超级棒的原因 .
:)
在大多数情况下，相对URL是可行的方式，它们本质上是可移植的，这意味着如果您想要提升您的网站并将其放在其他地方，它可以立即工作，从而减少可能数小时的调试 .
有一个相当不错的article on absolute vs relative URLs，检查一下 .
通常，最佳做法是使用相对URL，这样您的网站就不会绑定到当前部署的基本URL . 例如，它可以在localhost上工作，也可以在公共域上工作，无需修改 .
我应该使用绝对或相对URL吗？
如果绝对URL是指包括方案（例如http / https）和主机名（例如yourdomain.com）的URL，则不会这样做（对于本地资源），因为维护和调试会很糟糕 .
假设您在代码中使用了绝对URL，如
<img src="http://yourdomain.com/images/example.png">. 现在，当你要去的时候会发生什么：切换到另一个方案（例如http - > https）
切换域名（test.yourdomain.com - > yourdomain.com）
在第一个示例中，将发生的是您将收到有关页面上请求的不安全内容的警告 . 因为您的所有网址都是硬编码的，所以使用http（：//yourdomain.com/images/example.png） . 当通过http运行您的页面时，浏览器期望通过https加载所有资源以防止泄露信息 .
在第二个示例中，当您的网站从测试环境中直播时，这意味着所有资源仍然指向您的测试域而不是您的实时域 .
因此，要回答有关是使用绝对URL还是相对URL的问题：始终使用相对URL（对于本地资源） .
不同的URL有什么区别？
首先让我们看一下我们可以使用的不同URL：
http://yourdomain.com/images/example.png//yourdomain.com/images/example.png/images/example.pngimages/example.png这些URL尝试在服务器上访问哪些资源？
在下面的示例中，我假设网站从服务器
/var/www/mywebsite上的以下位置运行 .http://yourdomain.com/images/example.png
上述（绝对）URL尝试访问资源
/var/www/website/images/example.png. 出于上述原因，您始终希望避免这种类型的URL从您自己的网站请求资源 . 但它确实有它的位置 . 例如，如果您有一个网站http://yourdomain.com并且您想通过http从外部域请求资源，则应使用此方法 . 例如 .https://externalsite.com/path/to/image.png.//yourdomain.com/images/example.png
此URL是基于当前使用的方案的相对URL，并且在包含外部资源（图像，javascripts等）时几乎总是应该使用 .
这种类型的URL的作用是使用它所在页面的当前方案 . 这意味着您在页面
http://yourdomain.com并且该页面上是图像标记<img src="//yourdomain.com/images/example.png">图像的URL将在http://yourdomain.com/images/example.png中解析 .当你在页面
http**s**://yourdomain.com上并且在该页面上是图像标签<img src="//yourdomain.com/images/example.png">时，图像的URL将在https://yourdomain.com/images/example.png中解析 .这可以防止在不需要时通过https加载资源，并自动确保在需要时通过https请求资源 .
上述URL在服务器端以与先前URL相同的方式解析：
/images/example.png
对于本地资源，这是引用它们的首选方式 . 这是基于您网站的文档根目录（
/var/www/mywebsite）的相对URL . 这意味着当你有<img src="/images/example.png">时，它将始终解析为/var/www/mywebsite/images/example.png.如果在某些时候您决定切换域，它仍然可以工作，因为它是相对的 .
images/example.png
这也是一个相对URL，虽然与前一个有点不同 . 此URL与当前路径相关 . 这意味着它将根据您在站点中的位置解析到不同的路径 .
例如，当您在页面
http://yourdomain.com并且您使用<img src="images/example.png">时，它会在服务器上按照预期解析为/var/www/mywebsite/images/example.png，但是当您在页面http://yourdomain.com/some/path上并且使用完全相同的图像标记时，它会突然解析为/var/www/mywebsite/some/path/images/example.png.什么时候用？
在请求外部资源时，您很可能希望使用相对于方案的URL（除非您要强制使用其他方案），并且在处理本地资源时，您希望使用基于文档根目录的相对URL .
示例文档：
有些（有点）重复
Safe way to write URLs that transfer across environments
what is the correct way to link image in website?
看到：http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
一个绝对URL包括"path"部分之前的部分 - 换句话说，它包括方案（
http://foo/bar/baz在http://foo/bar/baz中）和主机名（foo在http://foo/bar/baz中）（以及可选的端口，userinfo和端口） .相对网址以路径开头 .
绝对的网址是绝对的：资源的位置只能在网址本身查找 . 相对URL在某种意义上是不完整的：要解决它，您需要方案和主机名，这些通常取自当前上下文 . 例如，在网页中
你可以把这样的链接
在链接的
href属性中，使用了相对URL，如果单击它，则必须解析它以便遵循它 . 在这种情况下，当前的上下文是所以这些的模式，主机名和前导路径都被采用并预先添加到
pages/page1，屈服如果链接是：
（注意
/出现在网址的开头）然后它将被解析为因为前导
/表示主机的根目录 .在Web应用程序中，我建议对属于您的应用程序的所有资源使用相对URL . 这样，如果您更改页面的位置，一切都将继续工作 . 任何外部资源（可能是完全在您的应用程序之外的页面，也是您通过内容传送网络提供的静态内容）应始终使用绝对URL指向：如果您不这样做，则根本无法找到它们，因为它们驻留在不同的服务器上 .
假设我们正在创建一个子网站，其文件位于文件夹http://site.ru/shop中 .
1.绝对网址
2.相对网址
虽然相对URL看起来比绝对URL短，但绝对URL更可取，因为链接可以在站点的任何页面上不加改变地使用 .
中级案例
我们考虑了两种极端情况：“绝对”绝对和“绝对”相对URL . 但在这个世界上，一切都是相对的 . 这也适用于URL . 每当你说绝对URL时，你应该总是指定相对于什么 .
3.协议相对URL
Google建议使用此类网址 . 但是，现在通常认为http：//和https：//是不同的站点 .
4.根相对URL
即相对于域的根文件夹 .
如果所有页面都在同一个域中，那么这是一个不错的选择 . 当您将站点移动到另一个域时，您不必在URL中大量替换域名 .
5.基本相对URL（主页相对）
标签<base>指定基本URL，它会自动添加到所有相关链接和锚点 . 基本标记不会影响绝对链接 . 作为基本URL，我们将指定主页：<base href =“http://sites.ru/shop/”> .
现在，您不仅可以将站点移动到任何域，还可以移动到任何子文件夹中 . 请记住，尽管URL看起来像是相对的，但实际上它们是绝对的 . 特别要注意锚点 . 要在当前页面中导航，我们必须编写href =“t-shirts / t-shirt-life-is-good /＃comments”而不是href =“＃comments” . 后者将扔在主页上 .
结论
对于内部链接，我使用基本相对URL（5） . 对于外部链接和新闻简报，我使用绝对URL（1） .
实际上应该明确讨论三种类型 . 实际上虽然URL被抽象为在较低级别处理，但我甚至可以说开发人员可以完成整个生命而无需手动编写单个URL .
绝对
绝对URL将您的代码与协议和域绑定在一起 . 这可以通过动态URL来克服 .
Absolute Pros:
Control - 可以控制子域和协议 . 通过一个不起眼的子域进入的人将被汇入正确的子域 . 您可以根据需要在安全和非安全之间来回跳转 .
Configurable - 开发人员喜欢绝对的东西 . 使用绝对URL时，您可以设计整洁的算法 . 可以对URL进行配置，以便可以在单个配置文件中进行单个更改，从而在站点范围内更新URL .
Clairvoyance - 您可以搜索抓取您网站的人，也可以搜索一些额外的外部链接 .
Root Relative
根相对URL将您的代码绑定到基本URL . 这个可以使用动态网址和/或base tags来克服 .
Root Relative Pros:
亲戚
相对URL将您的代码绑定到目录结构 . 没有办法克服这一点 . 相对URL仅在文件系统中用于遍历目录或作为琐事任务的快捷方式 .
Relative Cons:
CONFUSING - 那是多少个点？这是多少个文件夹？文件在哪里？为什么不工作？
MAINTENANCE - 如果文件被意外移动资源退出加载，链接会将用户发送到错误的页面，表单数据可能会被发送到错误的页面 . 如果要移动文件NEEDS，则需要更新所有要退出加载的资源以及所有不正确的链接 .
DOES NOT SCALE - 当网页变得更加复杂并且视图开始在多个页面中重复使用时，相对链接将相对于它们所包含的文件 . 如果你有一个HTML的导航片段将在每个页面上，那么亲戚将相对于许多不同的地方 . 人们在开始创建模板时首先意识到，他们需要一种管理URL的方法 .
COMPUTED - 它们由您的浏览器实现（希望根据RFC） . 见RFC3986中的第5章 .
OOPS! - 错误或拼写错误会导致蜘蛛陷阱 .
路线的演变
开发人员已经停止在此处讨论的意义上编写URL . 所有请求都是针对网站的索引文件，并包含查询字符串，即路径 . 该路由可以被视为一个迷你URL，告诉您的应用程序要生成的内容 .
Routes Pros:
绝对网址的所有优点 .
使用URL中的任何字符 .
更多控制（适合SEO） .
能够以算法方式生成URL . 这允许URL可配置 . 更改URL是单个文件中的单个更改 .
不需要404未找到 . 后备路由可以显示站点 Map 或错误页面 .
间接访问应用程序文件的便捷安全性 . Guard语句可以确保每个人都通过适当的渠道到达 .
MVC方法的实用性 .
我的看法
大多数人会以某种方式在他们的项目中使用所有三种形式 . 关键是要了解它们并选择最适合该任务的那个 .
以URL方案和方案特定部分（
http://，https://，ftp://等）开头的URL是绝对URL .任何其他URL都是相对URL，并且需要一个基本URL，相对URL是从中解析的（因此依赖于），如果没有另外声明，则是使用引用的资源的URL .
请查看RFC 2396 – Appendix C以获取解析相对URL的示例 .
假设您有一个网站www.yourserver.com . 在Web文档的根目录中，您有一个图像子指南，并且您有myimage.jpg .
绝对URL定义文档的确切位置，例如：
相对URL定义了相对于当前目录的位置，例如，假设您位于图像所在的根网站目录中：
（相对于该根目录）
您应该尽可能使用相对URL . 如果您将网站移至www.anotherserver.com，则必须更新指向www.yourserver.com的所有绝对URL，相关的URL将保持原样 .
对于支持相对URI解析的每个系统，相对URI和绝对URI都可以实现相同的目标：引用 . 它们可以互换使用 . 所以你可以在每种情况下做出不同的决定从技术上讲，它们提供相同的参考 .
确切地说，对于每个相对URI，已经存在绝对URI . 这就是解析相对URI的基URI . 因此，相对URI实际上是绝对URI之上的一个特性 .
这就是为什么使用相对URI可以做到更多，就像单独使用绝对URI一样 - 这对于静态网站来说尤其重要，否则与绝对URI相比，静态网站的维护难度不大 .
相对URI解析的这些积极影响也可以用于动态Web应用程序开发 . 在动态环境中，引入的不灵活绝对URI也更容易应对，因此对于一些不确定URI解析以及如何正确实现和管理它的开发人员（并不总是那么容易），通常选择使用绝对值在网站的动态部分中的URI，因为它们可以引入其他动态功能（例如，包含URI前缀的配置变量），以便解决不灵活性问题 .
那么使用绝对URI有什么好处呢？从技术上讲，没有，但我会说：相对URI更复杂，因为它们需要针对所谓的绝对基URI进行解析 . 即使分辨率严格定义多年，您也可能会遇到URI解析错误的客户端 . 由于绝对URI不需要任何解析，因此使用绝对URI不会因相对URI解析而遇到错误的客户端行为 . 那么实际风险有多高？嗯，这是非常罕见的 . 我只知道一个互联网浏览器有相对URI解析的问题 . 这不是一般情况，只是在一个非常（模糊）的情况下 .
在HTTP客户端（浏览器）旁边，对于超文本文档或代码的作者来说，它可能更复杂 . 这里绝对URI的优点是更容易测试，因为您只需将其按原样输入浏览器地址栏即可 . 但是，如果它不仅仅是您的一小时工作，那么实际了解绝对和相对URI处理通常会让您更有利，这样您就可以实际利用相对链接的好处 .
我衷心地建议将相同网址的相对URL推荐到同一网站的其他位 .
不要忘记，对HTTPS的更改 - 即使在同一站点中 - 也需要一个绝对URL .