硬件安全隔离级别不影响HTML沙箱工具选型，关键在虚拟化支持、浏览器版本及WebAssembly/GPU能力；隔离强度排序为iframe＞DOMParser+Proxy＞innerHTML；sandbox属性必须显式赋值如"allow-scripts"，空值将静默拦截。
硬件安全隔离级别不决定 HTML 沙箱函数工具的选型，只影响其运行时行为稳定性；真正该关注的是沙箱执行环境是否启用虚拟化支持、目标浏览器版本、以及是否需要 WebAssembly 线程或 GPU 加速等底层能力。
判断是否启用硬件虚拟化是前提，不是可选项
HTML 函数工具本身不依赖 CPU 虚拟化扩展（如 VT-x / AMD-V），但沙盒环境在容器、轻量 VM 或 WebView 中运行时，若底层未启用虚拟化，可能触发静默降级或崩溃：
- Chrome 在无 KVM 的 Linux 容器中启用
--ozone-platform=wayland会因 GPU 沙盒初始化失败而白屏，错误日志里看不到明确报错，只在chrome://gpu显示 GPU process crashed - WebAssembly 线程（
WASM Threads）在旧版 Chrome（≤119）中，若 CPU 不支持或 BIOS 关闭 VT-x，会抛出RuntimeError: unable to allocate memory for Wasm thread stack，而非优雅回退 - Node.js 环境下用
jsdom渲染 HTML 片段时，禁用虚拟化不会报错，但 V8 JIT 优化路径被绕过，performance.memory.totalJSHeapSize可能比启用时低 30%～40%
按隔离强度分三档：iframe > DOMParser + Proxy > innerHTML
所谓“HTML 函数工具”，本质是解析、执行、渲染不可信 HTML 字符串。不同方案的硬件级隔离能力差异极大：
-
iframe是唯一原生具备进程/页表级隔离的方案：同源时可设src="about:blank"后write()注入；跨域必须用Blob URL，每次生成新地址即新建独立文档上下文，变量、定时器、事件监听器全清空 -
DOMParser.parseFromString(html, 'text/html')仅提供 JS 执行上下文隔离（靠 Proxy 拦截全局对象），但所有脚本仍在主进程内运行，无法防内存越界或无限循环耗尽主线程 -
container.innerHTML = htmlString完全无隔离：子应用内联<script>直接污染window，样式逃逸到document.head，连eval都无需触发即可执行
sandbox 属性值必须显式声明，空值等于拒绝加载
这是最容易踩坑的地方：写 sandbox 或 sandbox="" 不是“开了沙箱”，而是让浏览器在解析响应体前就拦截整个 iframe 内容，Network 面板显示 net::ERR_BLOCKED_BY_RESPONSE，DOM 树为空，控制台静默——你根本看不到任何错误提示。
立即学习“前端免费学习笔记（深入）”；
- 最低可行配置是
sandbox="allow-scripts"：允许外链脚本执行，但window.origin强制为"null"，localStorage和document.cookie绑定到临时匿名上下文，刷新即丢 -
allow-same-origin仅当src与父页协议+域名+端口完全一致时才生效；否则浏览器静默忽略，你写的权限形同虚设 - 生产环境嵌入第三方插件，禁止组合使用
allow-scripts allow-same-origin allow-top-navigation——这等于把导航权、存储权、DOM 访问权全放开，和没加sandbox差不多
真正关键的不是“选哪个工具”，而是确认你的部署环境是否满足 Blob URL + sandbox="allow-scripts" 的最小闭环：每次 HTML 字符串都转成新 Blob 地址，iframe 加载完成后再 URL.revokeObjectURL()，同时所有状态同步只走 postMessage 并校验 event.origin。其他任何省事做法，都会在某个边缘 case 下暴露隔离缺口。
