<base>标签仅支持单一基准URL，无法实现多域名资源分发；重复声明时仅第一个生效，浏览器静默忽略后续标签，故不能通过多个<base>分别控制JS、图片、字体等不同资源的域名路径。
<base> 标签不能配置“不同域名”的资源路径——它只允许一个 href 值，且该值一旦设为跨域 URL（如 https://cdn.example.com/），所有纯相对路径都会被拼到那个域名下；你无法让它对部分资源走 A 域名、另一部分走 B 域名。
为什么<base href="https://a.com/">和<base href="https://b.com/">不能共存
浏览器强制要求整个文档中最多一个 <base>，重复声明时仅第一个生效，后续全部被忽略（Chrome 控制台会提示 Multiple base elements detected. Only the first one is used.）。这意味着：你不能靠多个 <base> 实现“JS 走 CDN、图片走图床、字体走另一域名”的分发逻辑。
- 想混用多源，必须放弃
<base>，改用显式绝对路径：<script src="https://js-cdn.example.com/app.js"></script>、<img src="https://img-storage.example.com/logo.png"> - 构建工具（如 Vite 的
build.assetsDir+ 自定义插件、Webpack 的publicPath函数）可按资源类型注入不同前缀，但最终仍需在 HTML 中写死或由服务端动态渲染 -
<base>的设计目标是统一基准，不是路由分发器——它的作用域仅限于 HTML 解析阶段的纯相对路径，不支持条件判断或正则匹配
href 写成 //cdn.example.com/ 还是 https://cdn.example.com/？
协议相对 URL（//cdn.example.com/）能自动继承当前页面协议（http: 或 https:），适合混合部署环境；但若页面本身是 file:// 协议（本地双击打开），它会退化为 file://cdn.example.com/，直接失败。
- 生产环境推荐完整绝对 URL：
<base href="https://cdn.example.com/v4/">—— 明确、可控、无歧义 - 若需兼容 HTTP/HTTPS 混合站（极少见），且确认页面永不以
file://打开，可用//cdn.example.com/v4/ - 禁止写
http://cdn.example.com/—— 现代浏览器对非 HTTPS 外部资源限制严格，可能被主动降级或拦截
CDN 域名变更时，如何避免硬编码泄露风险
把 CDN 域名写死在 HTML 里等于把基础设施细节暴露给前端，不利于灰度发布、A/B 测试或快速回滚。更健壮的做法是：由服务端或构建流程注入真实值。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- SSR 框架（如 Next.js、Nuxt）可在
getServerSideProps或head钩子中动态写入：<base href={cdnBaseURL}> - Vite 用户可通过
index.html中的%BASE_URL%占位符 +define配置替换（注意：必须确保构建时已替换，而非字面量字符串传到浏览器） - Webpack 用户应优先使用
publicPath配置，让所有 chunk、asset 自动带上 CDN 前缀，HTML 中反而不必手动加<base>—— 多数情况下这才是真正解耦的方式
最容易被忽略的跨域副作用：CSS 中的 url() 也被重写
当你设了 <base href="https://cdn.example.com/">，不仅 <img src="icon.png"> 会请求 https://cdn.example.com/icon.png，连 CSS 文件里写的 background: url(avatar.jpg); 也会被解析为 https://cdn.example.com/avatar.jpg —— 这是唯一穿透到 CSS 的情况，但常被误认为“CSS 不受 base 控制”。
- 如果 CSS 文件本身托管在另一个域名（如
https://css.example.com/style.css），而avatar.jpg本应从https://img.example.com/加载，那这个<base>就会导致图片 404 - 解决方案：CSS 中改用绝对 URL：
background: url(https://img.example.com/avatar.jpg);，绕过<base>干预 - 或者，干脆不设
<base>，全部资源路径显式声明，虽然啰嗦，但边界清晰
真正难的不是怎么写 <base>，而是意识到它根本不是为“多域名资源管理”设计的——一旦你开始琢磨怎么用它切分 CDN、图床、API 域名，说明该换思路了：要么交给构建工具做静态路径注入，要么由服务端动态渲染，要么接受显式写死的冗余，但换来的是确定性。
