如果是在你的网站中使用，最好使用相对URL，如果你需要将网站移动到另一个域名或只是在本地调试，你可以这样做。

看看stackoverflow在做什么(firefox中的ctrl+U):

<a href="/users/recent/90691"> // Link to an internal element

在某些情况下，他们使用绝对url:

<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">

．.． 但这只是提高速度的最佳做法。在你的情况下，你看起来不像这样做，所以我不会担心。

我衷心推荐使用相对url将同一站点的部分指向同一站点的其他部分。

不要忘记，即使在同一个站点中，更改到HTTPS也需要一个绝对URL。

以URL方案和方案特定部分(http://， https://， ftp://，等)开头的URL是绝对URL。

任何其他URL都是相对URL，并且需要一个基本URL，相对URL是从引用所使用的资源的URL中解析出来的(因此依赖于)，如果没有声明的话。

请参阅RFC 2396 -附录C中有关解析相对url的示例。

我不同意大多数人的观点。

我认为相对URL方案是“好的”，当你想快速启动和运行一些东西，而不是跳出框框思考，特别是如果你的项目很小，只有几个开发人员(或者只有你自己)。

然而，一旦您开始在大型的、臃肿的系统上工作，并且一直在切换域和协议，我相信一种更优雅的方法是合适的。

当你从本质上比较绝对和相对url时，绝对url胜出。为什么?因为它永远不会坏。永远。绝对URL就是它所描述的那样。问题是你必须维护你的绝对url。

The weak approach to absolute URL linking is actually hard coding the entire URL. Not a great idea, and probably the culprit of why people see them as dangerous/evil/annoying to maintain. A better approach is to write yourself an easy to use URL generator. These are easy to write, and can be incredibly powerful- automatically detecting your protocol, easy to config (literally set the url once for the whole app), etc, and it injects your domain all by itself. The nice thing about that: You go on coding using relative URLs, and at run time the application inserts your URLs as full absolutes on the fly. Awesome.

鉴于所有现代网站实际上都使用某种动态后端，这样做对网站最有利。绝对url的作用不仅仅是让你确定它们指向哪里——它们还可以提高SEO性能。

I might add that the argument that absolute URLs is somehow going to change the load time of the page is a myth. If your domain weighs more than a few bytes and you're on a dialup modem in the 1980s, sure. But that's just not the case anymore. https://stackoverflow.com/ is 25 bytes, whereas the "topbar-sprite.png" file that they use for the nav area of the site weighs in at 9+ kb. That means that the additional URL data is .2% of the loaded data in comparison to the sprite file, and that file is not even considered a big performance hit.

大的，未优化的，整个页面的背景图像更有可能减慢你的加载时间。

这里有一篇关于为什么不应该使用相对url的有趣文章: 为什么相对url应该被禁止

例如，可能会出现的一个问题是，有时服务器映射(请注意大型、混乱的项目)与文件名不一致，开发人员可能会对相对URL做出不正确的假设。我今天在我参与的一个项目上看到了这个，它把整个页面都拖下来了。

或者开发人员忘记切换指针，突然谷歌索引了整个测试环境。唉，重复的内容(不利于搜索引擎优化!)

绝对可能是危险的，但如果使用得当，并且不会破坏你的构建，它们被证明是更可靠的。看看上面的文章，它给出了一堆为什么Wordpress url生成器超级棒的理由。

:)

请看这个: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包括“路径”部分之前的部分——换句话说，它包括方案(http://foo/bar/baz中的http)和主机名(http://foo/bar/baz中的foo)(还有可选的port、userinfo和port)。

相对url以路径开头。

绝对URL是绝对的:资源的位置可以仅通过URL本身来解析。相对URL在某种意义上是不完整的:要解析它，您需要方案和主机名，而这些通常来自当前上下文。例如，在网页中

http://myhost/mypath/myresource1.html

你可以这样放一个链接

<a href="pages/page1">click me</a>

在链接的href属性中，使用了一个相对url，如果单击了它，则必须解析它以便跟随它。在本例中，当前上下文为

http://myhost/mypath/myresource1.html

因此，这些文件的模式、主机名和引导路径将被添加到pages/page1中，从而得到

http://myhost/mypath/pages/page1

如果链接是:

<a href="/pages/page1">click me</a>

(注意/出现在URL的开头)，那么它将被解析为

http://myhost/pages/page1

因为前导的/表示主机的根目录。

在一个web应用程序中，我建议对属于你的应用程序的所有资源使用相对url。这样，如果你改变了页面的位置，一切都将继续工作。任何外部资源(可以是完全在应用程序之外的页面，也可以是通过内容交付网络交付的静态内容)应该始终使用绝对url指向:如果不这样做，则根本无法定位它们，因为它们驻留在不同的服务器上。

一般来说，使用相对URL被认为是最佳实践，这样你的网站就不会被绑定到当前部署的基础URL。例如，它可以在本地主机上工作，也可以在您的公共域上工作，而无需修改。