在 iframe 中不穿透边界,仅作用于当前文档; 仅影响用户点击的无显式 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></a> 和 <form></form> 生效——且仅控制响应内容加载位置,不是导航指令。在三层 iframe 嵌套中,子 iframe 里的链接加了 <base target="_top">,点击后仍会加载到顶层窗口,但前提是该链接被用户直接点击;而 iframe src 切换、window.location.href、fetch() 全部无视它。
- 必须显式写
<a href="xxx" target="_top"></a>才可能触发顶级跳转 - 外层
<iframe></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,全都不抛异常,只留白屏或资源缺失。前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











