我从未见过<base> HTML标签实际上在任何地方使用。它的使用是否存在意味着我应该避免使用的陷阱?
事实上，我从未注意到它在现代生产站点(或任何站点)上使用过，这让我对它持怀疑态度，尽管它似乎在简化我站点上的链接方面有有用的应用程序。
Edit
After using the base tag for a few weeks, I did end up finding some major gotchas with using the base tag that make it much less desirable than it first appeared. Essentially, the changes to href='#topic' and href='' under the base tag are very incompatible with their default behavior, and this change from the default behavior could easily make third party libraries outside of your control very unreliable in unexpected ways, since they will logically depend on the default behavior. Often the changes are subtle and lead to not-immediately-obvious problems when dealing with a large codebase. I have since created an answer detailing the issues that I experienced below. So test the link results for yourself before you commit to a widespread deployment of <base>, is my new advice!
在页面中内联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标记，因为在我看来，它带来的问题比它解决的问题要多。
我将在为什么不应该设置<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指令添加到你的内容安全策略中。
我的建议是不要在管理url路径时使用<base>元素。为什么?
这只是把一个问题换为另一个问题。如果没有基本元素，您可以为相对路径和链接使用任何您喜欢的路径系统，而不必担心它们会中断。当你将基本元素设置为一个路径时，你就被“锁定”到设计所有url的工作路径，现在必须从基本路径更改所有路径。坏主意!
这意味着您现在必须编写更长的路径，并跟踪每条路径相对于这个基底的位置。更糟糕的是……当使用<base>元素时，他们建议您使用完全限定的基本路径来支持旧的浏览器(“https://www.example.com/”)，所以现在您已经将域硬编码到页面中，或者使所有链接依赖于有效的域路径。
另一方面，当你再次从你的网站中删除基本路径时，你现在可以再次自由地使用更短的相对路径，这可以是完全限定的，从根目录使用绝对路径，或者使用真正相对于你所在的文件和文件夹的路径。它更灵活。最好的是，像“#hello”这样的片段可以正常工作，不需要任何额外的修复。再说一次，人们在制造不存在的问题。
另外，上面提到的使用基本url来帮助您将网页文件夹迁移到新的子文件夹位置的论点在今天并不重要，因为大多数现代服务器允许您快速将任何子文件夹设置为任何域下的新应用程序根文件夹。web应用程序的定义或“根”现在不受文件夹或域的限制。
这场争论看起来有点傻。因此，我建议去掉base url，并支持不使用它的旧的本地服务器-客户机默认路径系统。
注意:如果你的问题是控制路径由于一些新的API系统，解决方案很简单…在API中所有url和链接的路径上保持一致。不要依赖于浏览器对base或HTML5的支持，也不要像javascript API小孩子那样依赖于更新的马戏团把戏。简单地路径所有的锚标签一致，你将永远不会有问题。更重要的是，不管使用什么路径系统，您的web应用程序都可以立即移植到新的服务器上。
旧的又变新了!基本元素显然是试图为20年前的Web世界中从未存在过的问题创建解决方案，更不用说今天了。
