<base>标签写错会导致CSS等资源404，因其校验严格：href必须以http://、https://、//或/开头且结尾带/，否则静默丢弃，使相对路径退回到当前页URL解析。
<base> 标签本身不会“缺失导致样式丢失”——它只在显式写入且合法时才起作用；没写 <base>，浏览器就按默认规则解析相对路径，通常反而更稳定。真正出问题的，是写了但写错了，或者写了却没意识到它已悄悄改写所有相对 URL 的解析逻辑。
为什么写了 <base href> 反而让 CSS 404
浏览器对 <base href> 的校验极严格：值必须以 http://、https://、// 或 / 开头，且以 / 结尾，否则整条标签被静默丢弃——不报错、不警告，但后续所有相对路径（如 <link href="css/app.css">）都退回到按当前页面 URL 解析，极易批量 404。
-
<base href="subapp/">→ 开头不是协议或/，丢弃 -
<base href="/myapp">→ 结尾缺/，Firefox/Opera 会拼出/myappcss/app.css -
<base href="%PUBLIC_URL%">→ 构建未替换时就是字面量，非法，丢弃
如何确认 <base> 是否生效
别信源码里“写了就行”，得验证它真被浏览器采纳：
- 打开开发者工具 → Elements → 检查
<head>最顶部是否唯一存在<base>，且href值符合https://...、//...或/xxx/格式 - 右键页面 → “查看网页源代码”（Ctrl+U），确认
<base>在<head>第一行，且前面没有<title>、<meta>等任何标签 - 在控制台执行
document.querySelector('base')?.href，返回空字符串或undefined就说明没生效
构建工具与 <base> 的协同陷阱
Vite、Webpack 等工具的 base 配置（如 base: "/admin/"）只影响资源前缀生成逻辑，不会自动修正你手写的 <link href="style.css">——它仍按 <base> 规则解析。两者不一致就会断裂：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- Vite 设置
base: "/admin/"，但 HTML 里漏写<base href="/admin/">→style.css被请求为/style.css（404） - 写了
<base href="/admin/">，但 Vitebase配置为"/"→ CSS 文件产出在dist/style.css，却被请求为/admin/style.css（404） - Tauri 或 Electron 中用
file://协议加载页面时，<base href="/app/">会强制转成file:///app/style.css，而实际文件在file:///path/to/dist/style.css，必然失败
CSS 404 时优先排查 <base> 而非文件路径
当 Network 面板看到 main.123abc.css 返回 404，第一反应不该是“CSS 文件没打包出来”，而是看它请求的完整 URL 是什么：
- 如果是
https://example.com/css/main.123abc.css→ 检查服务端静态资源目录结构 - 如果是
https://example.com/admin/css/main.123abc.css→ 回头查<base href>和构建配置是否匹配 - 如果是
https://example.com/subappmain.123abc.css（中间缺/）→<base href="/subapp">末尾缺斜杠，立刻修复
最易被忽略的点：动态插入 <base>（如 document.head.appendChild(baseEl)）完全无效——HTML 解析阶段早已结束，此时加进去只是个普通 DOM 节点，不影响任何 URL 解析。
