Drupal最初依赖于<base>标记，后来由于HTTP爬虫和缓存的问题决定不再使用。

我一般不喜欢发布链接。但这一点真的值得分享，因为它可以让那些寻找<base>标签的真实世界体验细节的人受益:

http://drupal.org/node/13148

Drupal最初依赖于<base>标记，后来由于HTTP爬虫和缓存的问题决定不再使用。

我一般不喜欢发布链接。但这一点真的值得分享，因为它可以让那些寻找<base>标签的真实世界体验细节的人受益:

http://drupal.org/node/13148

好吧，等一下。我认为基本标签配不上这种坏名声。

base标记的优点是它使您能够以更少的麻烦进行复杂的URL重写。

举个例子。您决定将http://example.com/product/category/thisproduct移动到http://example.com/product/thisproduct。修改.htaccess文件，将第一个URL重写为第二个URL。

有了base标签，就可以重写.htaccess了。没有问题。但是如果没有base标签，所有的相对链接都将中断。

URL重写通常是必要的，因为调整它们可以帮助您的网站的架构和搜索引擎可见性。的确，对于人们提到的“#”和“”问题，您需要变通方法。但是基本标记应该在工具包中占有一席之地。

我的建议是不要在管理url路径时使用<base>元素。为什么?

这只是把一个问题换为另一个问题。如果没有基本元素，您可以为相对路径和链接使用任何您喜欢的路径系统，而不必担心它们会中断。当你将基本元素设置为一个路径时，你就被“锁定”到设计所有url的工作路径，现在必须从基本路径更改所有路径。坏主意!

这意味着您现在必须编写更长的路径，并跟踪每条路径相对于这个基底的位置。更糟糕的是……当使用<base>元素时，他们建议您使用完全限定的基本路径来支持旧的浏览器(“https://www.example.com/”)，所以现在您已经将域硬编码到页面中，或者使所有链接依赖于有效的域路径。

另一方面，当你再次从你的网站中删除基本路径时，你现在可以再次自由地使用更短的相对路径，这可以是完全限定的，从根目录使用绝对路径，或者使用真正相对于你所在的文件和文件夹的路径。它更灵活。最好的是，像“#hello”这样的片段可以正常工作，不需要任何额外的修复。再说一次，人们在制造不存在的问题。

另外，上面提到的使用基本url来帮助您将网页文件夹迁移到新的子文件夹位置的论点在今天并不重要，因为大多数现代服务器允许您快速将任何子文件夹设置为任何域下的新应用程序根文件夹。web应用程序的定义或“根”现在不受文件夹或域的限制。

这场争论看起来有点傻。因此，我建议去掉base url，并支持不使用它的旧的本地服务器-客户机默认路径系统。

注意:如果你的问题是控制路径由于一些新的API系统，解决方案很简单…在API中所有url和链接的路径上保持一致。不要依赖于浏览器对base或HTML5的支持，也不要像javascript API小孩子那样依赖于更新的马戏团把戏。简单地路径所有的锚标签一致，你将永远不会有问题。更重要的是，不管使用什么路径系统，您的web应用程序都可以立即移植到新的服务器上。

旧的又变新了!基本元素显然是试图为20年前的Web世界中从未存在过的问题创建解决方案，更不用说今天了。

在AngularJS中，BASE标签默默地破坏了$cookieStore，我花了一段时间才弄清楚为什么我的应用程序不能再编写cookie了。警告……

在页面中内联SVG图像的情况下，当使用基本标签时，会出现另一个重要的问题:

因为使用基标记(如上所述)，您实际上失去了使用相对散列url的能力，如in

<a href=“#foo”>

因为它们将根据基URL而不是当前文档的位置进行解析，因此不再是相对的。 因此，您必须将当前文档的路径添加到这些类型的链接，如in

<a href=“/path/to/this/page/name.html#foo”>

因此，base标记的一个看似积极的方面(将长URL前缀从锚标记中移开，并获得更好、更短的锚)对于本地哈希URL完全适得其反。

当在页面中内联SVG时，这尤其令人讨厌，无论是静态SVG还是动态生成的SVG，因为在SVG中可能有很多这样的引用，并且在大多数(但不是所有)用户代理实现中，只要使用了基本标记，它们就会全部中断(至少Chrome在编写本文时仍然可以在这些场景中工作)。

如果您正在使用模板系统或其他工具链来处理/生成页面，我总是会尝试摆脱base标记，因为在我看来，它带来的问题比它解决的问题要多。