<base>标签对SVG中纯相对路径的href（如<use href="sprite.svg#icon">、<image href="logo.png">）生效，但对根相对路径、绝对URL、data URL及片段标识符（如href="#icon"）完全无效；内联CSS/SVG中的url(#id)引用不受任何影响。
<base> 标签对 SVG 内部的路径（如 <use href="#icon">、<image xlink:href="logo.png">）**基本不生效**，但存在几个关键例外和隐式依赖点，容易误判为“生效”或“失效”。
SVG 的 href 和 xlink:href 是否受 <base> 控制？
现代浏览器中，<use href="..."></use> 和 <image href="..."></image>（已弃用 xlink:href）中的相对 URL **受 <base> 影响**——前提是这些属性值是纯相对路径（即不以 /、: 或协议开头）。
例如：
<base href="https://cdn.example.com/assets/"> <svg> <use href="sprite.svg#home"></use> <image href="icon.png"></image> </svg>
此时 href="sprite.svg#home" 会被解析为 https://cdn.example.com/assets/sprite.svg#home；href="icon.png" 同理。
立即学习“前端免费学习笔记（深入）”；
但以下情况完全绕过 <base>：
-
href="/icons/home.svg"（根相对路径 → 直接拼到域名下） -
href="data:image/svg+xml,..."（完整 data URL） -
href="https://example.com/logo.svg"（绝对 URL） -
<use href="#local-symbol">（片段标识符，不触发网络请求）
内联 SVG 中的 url() 函数（如 fill: url(#gradient)）是否受影响？
完全不受影响。url(#gradient) 是 CSS 或 SVG 自身的引用语法，不是资源加载路径，<base> 对其无任何作用。它只在当前文档内查找 ID 为 gradient 的定义，与外部路径无关。
同理：<linearGradient href="#base-gradient"> 中的 href 也仅用于 SVG 元素间引用，不走 URL 解析流程。
为什么有时感觉 SVG 图标“突然 404”，怀疑是 <base> 搞的鬼？
真正原因往往藏在这几个地方：
-
<base href="/subapp/">写对了，但构建工具（如 Vite）也配了base: '/subapp/'→ 导致sprite.svg实际被请求为/subapp//subapp/sprite.svg（双斜杠），服务端返回 404 - SVG 文件里用了
<image href="logo.png">，但该 SVG 是通过<img src="icon.svg">加载的 —— 此时<img>的src受<base>影响，而 SVG 内部的<image href>会以 **SVG 文件自身所在 URL 为基准** 解析（不是 HTML 页面的baseURI） - 服务端渲染时动态注入了多个
<base>，浏览器只认第一个，但 SVG 加载时机早于第二个<base>，导致部分资源按错误 base 解析
验证 SVG 路径是否真被 <base> 改写？
最直接的方法是打开 DevTools → Network 面板，过滤 svg 或 png，点击触发加载的元素（如 <use> 所在容器），看实际发起的请求地址是否符合 <base href> 值 + 相对路径的拼接结果。
注意：如果请求地址看起来“对”，但图标仍不显示，大概率是 SVG 文件本身内容有误（比如 #icon ID 不存在），而不是 <base> 问题。
复杂点在于：SVG 外部引用（<use href="file.svg#id">）和内部引用（<use href="#id">）共存时，前者走 <base> 解析，后者完全不走网络 —— 这种混合模式最容易让人忽略上下文切换。
