另外，你应该记住，如果你在非标准端口上运行你的web服务器，你也需要在base href上包含端口号:

<base href="//localhost:1234" />  // from base url
<base href="../" />  // for one step above

还有一个站点使用了base - tag，出现了描述的问题。(升级jquery后)，能够修复它有TAB url像这样:

<li><a href="{$smarty.server.REQUEST_URI}#tab_1"></li>

这使得他们“本地化”

我使用的参考资料:

http://bugs.jqueryui.com/ticket/7822 http://htmlhelp.com/reference/html40/head/base.html http://tjvantoll.com/2013/02/17/using-jquery-ui-tabs-with-the-base-tag/

它可能不是很流行，因为它不是很出名。我不会害怕使用它，因为所有主流浏览器都支持它。

如果您的站点使用AJAX，您将希望确保所有页面都正确设置了AJAX，否则可能会出现无法解析的链接。

只是不要在HTML 4.01 Strict页面中使用target属性。

我从来没觉得用它有什么意义。提供很少的优势，甚至可能使一些东西更难使用。

除非您碰巧有数百或数千个链接，所有链接都指向同一子目录。这样可以节省几个字节的带宽。

事后想起来，我似乎记得IE6中的标签有一些问题。您可以将它们放置在主体的任何位置，将站点的不同部分重定向到不同的位置。这个问题在IE7中得到了修复，IE7破坏了很多网站。

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

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

http://drupal.org/node/13148

我将在为什么不应该设置<base href>标记的长长的原因列表中再添加一个参数。正如许多人在这里注意到的，设置<base href>会改变#anchor和?query URL的行为——它们附加到基本href，而不是文档自己的URL的回退基础。

您可能认为设置<base href="https://example.com/the/documents/own/url">可以解决这个问题，并且一切都将正常运行。你错了。

在现实世界的web中，?query=参数一直用于会话属性(如谷歌Analytics)和许多其他事情。这些参数中有许多是专门供脚本在客户端使用的;服务器不会关心它们，也不会对它们做任何事情。

假设您正在为example.com/landing-page提供服务，其中包含<base href="example.com/landing-page">，并且页面上有一个到#菜单的链接。然后有人通过URL example.com/landing-page?source=my-marketing-campaign到达那里。

如果没有<base href>，当他们单击#菜单时，浏览器将识别页面内导航并立即跳转到该部分。

但是，由于定义的base href example.com/landing-page缺少查询参数source=my-marketing-campaign，浏览器不能确定它是一个页面内链接。因此，单击#menu将触发一个新的HTTP请求，页面(及其所有非缓存资产)将重新加载。最好的情况是，这是对各方时间和带宽的毫无意义的浪费。在最坏的情况下，状态和数据可能会丢失。

对于静态站点来说，这是没有办法的。如果您正在使用CMS，您可能会想一下，您可以动态地将<base href>设置为请求URL，包括所有参数。虽然这可以解决刷新问题，但最终会遇到缓存问题和噩梦般的安全漏洞。

底线:<base href>会给你带来麻烦，不管你把它设置成什么。不要这样做。

如果你担心恶意脚本可能会注入自己的<base href="evil.com">标记(例如在nonce重定向攻击中)，2022年的最佳解决方案似乎是将base-uri指令添加到你的内容安全策略中。