<base href> 在 iframe 中不穿透边界，仅作用于当前文档；<base target="_top"> 仅影响用户点击的无显式 target 的链接，且需外层 iframe 启用 sandbox="allow-top-navigation" 才生效。
base href 在 iframe 嵌套中根本不起作用
<base href> 只影响当前 HTML 文档解析时的相对路径，不穿透 iframe 边界。哪怕父页、子页都写了 <base href="/subapp/">，子 iframe 里 <img src="logo.png"> 仍以子页面自身的 URL 为基准解析，不是父页的 base。浏览器把每个 iframe 当作独立文档环境，document.baseURI 在子 iframe 中只读取它自己 HTML 里的 <base>（或 fallback 到自身 URL），不会继承外层。
base target="_top" 对 iframe 内导航无效
<base target="_top"> 不会让 iframe 自己“跳出”。它只对当前文档内用户点击的、未显式写 target 的 <a> 和 <form> 生效——且仅控制响应内容加载位置，不是导航指令。在三层 iframe 嵌套中，子 iframe 里的链接加了 <base target="_top">，点击后仍会加载到顶层窗口，但前提是该链接被用户直接点击；而 iframe src 切换、window.location.href、fetch() 全部无视它。
- 必须显式写
<a href="xxx" target="_top">才可能触发顶级跳转 - 外层
<iframe>必须带sandbox="allow-top-navigation"，否则target="_top"被静默忽略 - 目标页若返回
X-Frame-Options: DENY或Content-Security-Policy: frame-ancestors 'none'，跳转会被拦截，控制台只报Refused to display 'xxx' in a frame
嵌套中 document.baseURI 是局部的，别指望它统一 API 请求
子 iframe 的 document.baseURI 取决于它自己 HTML 中的 <base href>，和父页无关。这意味着：子 iframe 里执行 fetch('./api/user')，实际请求地址是 https://parent.com/child.html 所在域 + 子 iframe 的 document.baseURI 拼出的路径，不是父页的上下文。结果常是 404，尤其当后端 API 部署在根路径或独立域名下。
-
fetch()、import()、new Worker()、XMLHttpRequest全部按document.baseURI解析相对 URL - 这个行为在 Chrome/Firefox/Safari 一致，且无法被服务端重定向绕过
- 微前端场景下，子应用若依赖
document.baseURI构造资源路径，而主应用没同步注入匹配的<base>，就会 chunk 加载失败或 hydration 错位
多层嵌套时 base 和构建工具配置极易冲突
如果子 iframe 页面由 Vite 构建并设了 build.base = "/subapp/"，又手动在 HTML 中加了 <base href="/subapp/">，资源路径会被拼两次：/subapp//subapp/js/app.js —— 中间双斜杠导致 404。这种错误在 Network 面板里一眼可见，但开发时容易漏看。
立即学习“前端免费学习笔记（深入）”；
- Vite/Webpack 的
base/publicPath是构建时重写，<base>是运行时解析，二者叠加必错 - 子 iframe 页面若用 SSR 渲染，服务端模板必须和客户端一致注入
<base>，否则首屏资源路径对、hydration 后路径错 - 本地开发时用
http://localhost:3000/作href比用/更安全，能避免和后端路由规则冲突
<base> 静默失效、fetch() 拼错 API、子应用 chunk 404，全都不抛异常，只留白屏或资源缺失。 
