base href必须是完整绝对URL（如https://cdn.example.com/v3.1/），否则静默失效导致批量404；仅影响HTML属性中纯相对路径，对JS/CSS运行时路径无效。
base href 必须是完整绝对 URL，否则云存储路径失效
云存储（如 CDN、OSS、S3）迁移时，<base href> 是最轻量级的路径重定向方案，但前提是 href 值必须是完整绝对 URL，例如 https://cdn.example.com/v3.1/。浏览器只接受以 https://、http://、// 或 / 开头的值；写成 cdn.example.com/v3.1/（缺协议）或 /v3.1/（根相对，依赖当前域名）都会被静默忽略——所有 <img src="logo.png"> 仍按原始页面 URL 拼接，结果就是批量 404。
常见翻车点：
-
<base href="static/">：无协议无域名，直接失效 -
<base href="https://cdn.example.com">：结尾缺/，Firefox/Opera 会把css/app.css拼成https://cdn.example.comcss/app.css -
<base href="//cdn.example.com/v3.1/">：协议相对 URL，在部分旧环境或本地file://下行为不稳定
哪些资源能借 base 标签迁移到云存储，哪些不能
<base> 只在 HTML 解析阶段生效，它改写的是硬编码在标签属性里的纯相对路径（即不以 /、: 或协议开头的值）。这意味着：
✅ 真正受控（可一键迁移到云存储）：
立即学习“前端免费学习笔记（深入）”；
<img src="icon.svg"><script src="bundle.js"><link href="theme.css">- CSS 中的
background: url(avatar.jpg)（唯一穿透到 CSS 的情况）
❌ 完全不受控（base 标签对它们无效，必须单独处理）：
fetch('./api/data.json')import('./utils.js')new Worker('./worker.js')- CSS 中的
@import "reset.css" -
<iframe src="page.html">（src 相对于 iframe 当前 URL）
与构建工具 publicPath / base 配置的冲突风险
现代打包工具（Webpack/Vite）本身就有 publicPath 或 build.base 配置项，它们会在构建时重写静态资源路径。如果同时手动加 <base href="/subapp/">，极易导致路径被拼两次：
- Webpack
publicPath: '/subapp/'+ HTML<base href="/subapp/">→ 实际请求变成/subapp//subapp/js/app.js - Vite
build.base: '/subapp/'已自动注入<base href="/subapp/">，再手写一条等于重复 - Vue Router 的
base: '/subapp/'和 HTML<base>是两套独立机制：只设一个，路由跳转或资源加载必出问题
云存储场景下，更稳妥的做法是：构建时用完整 CDN 地址配置 publicPath（如 https://cdn.example.com/v3.1/），然后彻底不用 HTML <base> —— 避免双层控制带来的不可预测性。
本地调试与生产环境的 href 写法差异
本地开发时，用 http://localhost:3000/ 作 <base href> 比用 / 更安全，能避免和后端路由（如 Express 的 app.use('/api', ...)）冲突；而部署到云存储后，必须切换为完整绝对 URL。
不要依赖模板变量（如 %PUBLIC_URL% 或 {{ .Site.BaseURL }}）直接塞进 <base> —— 如果变量展开失败，值变成空字符串或相对路径，整个 <base> 就被静默丢弃，你根本收不到报错。
真正关键的检查点只有两个：是否放在 <head> 最前面、href 值是否以 https:// 开头且结尾带 /。其他所有“看起来合理”的写法，都可能让迁移后的页面一半资源加载成功、一半 404，而且 Network 面板里连警告都没有。
