base href 一加就全乱了，因其强制重写所有相对 URL 解析起点，导致 img、a、form 等路径错乱；必须置于 head 内且唯一，href 值须为绝对 URL 或根相对路径（如 /my-app/），否则静默失效或引发 404。
base href 为什么一加就全乱了
因为 <base> 不是“辅助工具”，而是浏览器解析所有相对 URL 的强制起点。一旦声明，src、href、form action 甚至 window.location.href 中的相对跳转，都会被重算——它不区分资源类型，也不看上下文。
常见错误现象：<img src="logo.png"> 突然请求 /css/logo.png；点击导航链接跳到 /admin/login 却打开 /login；控制台报 404 的路径和你写的完全对不上。
- 必须放在
<head>内，且只能有一个 —— 多个会被忽略最后一个 -
href值不能是相对路径（比如href="assets/"），否则基准本身又变成相对的，行为不可控 - 如果项目部署在子路径（如
https://example.com/my-app/），href必须写成/my-app/，而不是/或./ - 开发时用
http://localhost:3000/，上线后切到https://example.com/，<base href>就得同步改，硬编码容易漏
href="/" 和 href="https://example.com/" 有啥区别
表面看都是“从根开始”，但实际影响不同：前者是根相对路径（protocol-relative），后者是绝对 URL。关键差异在协议、端口、子路径三处。
例如当前页面是 https://example.com:8080/blog/post.html：
立即学习“前端免费学习笔记（深入）”；
-
<base href="/">→ 所有相对路径以https://example.com:8080/为基准（保留原协议+主机+端口） -
<base href="https://example.com/">→ 强制走https://example.com/（丢掉端口 8080，且固定 https） - 若部署在 GitHub Pages（地址形如
https://user.github.io/repo/），href="/"会指向https://user.github.io/（根），而非你的repo子目录，必然 404
所以 href="/" 更安全，但前提是你的整个站点确实部署在域名根下；否则必须带子路径，比如 href="/repo/"。
不写 base，但想统一路径，该用什么
直接放弃全局修正幻想，改用根相对路径（root-relative URL）——也就是所有 src 和 href 都以 / 开头。
-
<script src="/js/app.js"></script>→ 解析为https://example.com/js/app.js，与当前页面路径无关 - 适用于静态资源（CSS、JS、图片、字体），也适用于
<a href="/about">这类内部链接 - 唯一前提：服务器必须把
/js/app.js映射到真实文件（如 Nginx 的location /js/ { alias /path/to/static/js/; }） - 注意：Django/Flask 等框架通常通过
STATIC_URL = '/static/'控制前缀，此时应写src="/static/js/app.js"，不是/js/
开发者工具里怎么看 base 是否生效
别猜，直接看 Network 面板里每个请求的真实 URL —— 那才是最终结果。
操作步骤：
- 打开 DevTools → Network → 刷新页面
- 点一个失败的
script请求 → 查看 Headers → 找Request URL - 对比这个 URL 和你写的
src值，再对照<base href>值，手算是否匹配（例如base href="/app/"+src="main.js"→ 应为/app/main.js） - 如果
Request URL明显多了一级或少了一级，大概率是../层级错了，或者<base>的href没对齐部署结构
真正卡住的地方，往往不是语法写错，而是 <base href> 的值和实际部署路径之间差了半层目录 —— 比如本地跑在 /，上线却放在 /v2/，而你忘了改 href。
