innerHTML = htmlString不能当沙箱用，因其绕过所有隔离逻辑：内联<script>在主应用全局执行、<style>注入document.head导致样式污染、相对路径资源404，且无法重写路径或沙箱化脚本；DOMParser解析是必选项，用于提取纯净DOM、补全绝对路径、沙箱执行脚本、隔离样式。
直接用浏览器打开 .html 文件最简单，但真要安全运行不可信代码，必须用 srcdoc + sandbox 或 DOMParser + iframe，否则脚本逃逸、样式污染、白屏问题几乎必然发生。
为什么 innerHTML = htmlString 不能当沙箱用
这是前端微模块/微前端中最常见的误操作：把从服务端 fetch 到的 HTML 字符串直接塞进 container.innerHTML。它看似能渲染，实则完全绕过所有隔离逻辑。
- 内联
<script>会直接执行在主应用全局作用域，污染window、覆盖变量、触发重复初始化 - 内联
<style>会注入到主页面document.head，造成样式泄漏（比如子应用的body { margin: 0 }把整个主站撑开） - 相对路径资源（
src="./main.js"）会拼错成https://main.com/./main.js，404 加载失败 - 没有 DOMParser 解析步骤，就无法提取、重写、沙箱化资源节点——这步不是可选项，是必选项
用 srcdoc 做轻量沙箱的硬性条件
srcdoc 看似方便，但不设防等于裸奔。它默认禁用脚本、禁止访问父页面、无 cookie、无 localStorage，但一旦配错 sandbox 属性，立刻失效。
- 必须显式写
sandbox="allow-scripts"——srcdoc默认连<script>都不执行，不加这句就是纯静态 HTML - 绝对禁止
sandbox="allow-scripts allow-same-origin"—— 这会让 iframe 拥有和主页面同源权限，可读取localStorage、调用parent.XXX，沙箱形同虚设 - 所有 HTML 字符串必须先过
DOMPurify.sanitize()，或至少手动移除<script>、onerror=、javascript:等危险内容 -
<style>必须内联，外部<link>会被sandbox拦截；CSS 类名建议加前缀（如widget-xxx），避免被主页面样式覆盖
DOMParser 是 HTML Entry 加载不可跳过的一步
微前端里加载子应用 HTML 入口时，DOMParser 不是“增强体验”，而是隔离底线。它把原始字符串转为标准 Document 对象，才能逐项控制每个节点的命运。
立即学习“前端免费学习笔记（深入）”；
- 用
new DOMParser().parseFromString(html, 'text/html')解析，得到干净的文档结构 - 从
doc.body.innerHTML提取挂载内容，避开原始<head>中的全局副作用 - 遍历
doc.head.querySelectorAll('script, link[rel="stylesheet"], style')，对每个src/href调用new URL(attrValue, response.url)补全为绝对路径 - 内联
<script>不直接执行，交由 JS 沙箱（如 Proxy 沙箱）运行；<style>内容提取后注入子容器或shadowRoot.adoptedStyleSheets
iframe 是唯一真正 HTML 层级的 JS 沙箱
Proxy 沙箱、快照沙箱都只是 JS 执行时的模拟，子应用仍可通过 eval、Function 构造器、with 等方式逃逸。只有 iframe 在浏览器原生层面切断了执行上下文。
- 同域 iframe 推荐用
src="about:blank"后调用contentWindow.document.write()注入 HTML，再.close()触发解析 - 必须显式设置
<base href="https://sub.example.com/">，否则所有相对路径资源都会以主应用域名解析 - 动态
fetch('/api')在 iframe 内会发向主应用域名，需在沙箱中重绑定window.fetch并补全 base URL - 样式卸载依赖容器移除触发 CSSOM 重建，但若子应用越界操作
document.head或挂载组件到document.body，隔离立即失效——这类问题比 JS 沙箱逃逸更隐蔽、更难排查
真正难的不是让代码跑起来，而是让它跑得干净、可控、可卸载。沙箱不是加个属性就完事，每一步解析、路径重写、资源注入、执行绑定，都在决定是否真的隔离成功。
