<base>标签与防止资源劫持无关，仅用于重写HTML中纯相对路径的解析起点；防劫持需依赖HTTPS、SRI、CSP等机制。
<base> 标签和“防止资源劫持”没有关系。它既不能防劫持，也不参与安全控制——这是个常见误解。
base 标签根本不管资源劫持
资源劫持（比如 CDN 被污染、脚本被中间人篡改）靠的是 HTTPS + 完整性校验（integrity）、子资源完整性（SRI）、CSP 等机制。<base href="..."> 只干一件事：在 HTML 解析阶段，重写纯相对路径（如 logo.png）的解析起点。它不加密、不校验、不拦截、不审计任何请求。
你加了 <base href="https://cdn.example.com/v4/">，浏览器照样会发请求；如果那个 CDN 域名被 DNS 劫持或证书被伪造，<base> 不会阻止、不会报警、也不会 fallback。
常见误操作包括：
立即学习“前端免费学习笔记（深入）”；
- 以为写
<base href="https://trusted-cdn.com/">就等于“锁定可信源”，其实只是改变了路径拼接逻辑 - 把
<base>和 CSP 的script-src混为一谈，后者才真正限制哪些域名能执行脚本 - 在未启用 HTTPS 的页面上硬塞 HTTPS 的
base href，导致混合内容被浏览器主动阻断（Mixed Content blocking）
base 标签写错反而制造 404 和加载漏洞
写错 href 值是静默失效，不是报错。这意味着你自以为“所有资源都走 CDN”，实际它们全按当前页面 URL 加载，可能从不可信的同域路径拉取 JS/CSS，反而扩大攻击面。
典型翻车点：
-
<base href="cdn/">→ 浏览器直接忽略，<script src="app.js">仍走https://attacker.com/app.js -
<base href="/sub/">（缺末尾斜杠）→ Firefox 拼成/subjs/app.js，404 后可能触发错误 fallback 逻辑，甚至加载默认路径的恶意资源 -
<base href="https://cdn.example.com">（结尾没/）→ 拼出https://cdn.example.comstyle.css，同样 404 或加载错文件
这些 404 不仅影响功能，还可能暴露内部路径结构、触发监控告警缺失、或让前端错误处理逻辑降级到不可控状态。
真正该配的安全机制（和 base 无关）
要防资源劫持，必须用以下组合，且 <base> 不能替代其中任何一项：
- 强制 HTTPS：所有资源协议统一为
https://，避免明文传输被篡改 - SRI（子资源完整性）：
<script src="https://cdn.example.com/app.js" integrity="sha384-...">，浏览器校验哈希后才执行 - CSP（内容安全策略）：
Content-Security-Policy: script-src 'self' https://cdn.example.com; require-trusted-types-for 'script'; - HTTP 严格传输安全（HSTS）：防止首次访问被降级到 HTTP
注意：<base> 的 href 值若含协议，必须与 CSP 中允许的域名一致，否则即使路径拼对了，CSP 也会拦截请求。
base 标签唯一“安全相关”的实操建议
它唯一的间接安全价值，是减少硬编码路径带来的维护盲区，从而降低因路径错误引入的意外加载风险。但前提是写法绝对合规：
- 只用两种形式：
<base href="https://cdn.example.com/v5/">（推荐 CDN 场景）或<base href="/myapp/">（子路径部署，开头结尾都必须是/） - 必须放在
<head>最前面，在所有<link>、<script>之前 - 不要和构建工具重复配置：Vite 的
build.base或 Webpack 的publicPath已设好时，HTML 中就别再手动写<base>，否则双拼路径可能绕过 SRI 或 CSP 白名单 - 本地开发慎用
<base href="/">：容易和后端路由冲突，导致 API 请求也被错误重写（如fetch("api/user")不受影响，但<form action="api/login">会被 base 改写）
最常被忽略的点：哪怕你把 <base> 写得完全正确，它也只影响 HTML 属性里的纯相对路径；所有 JS 中的 fetch、import、new Worker、CSS 中的 @import 全部绕过它——这些才是现代前端真正的资源加载主路径，它们的安全必须单独加固。
