加 sandbox 不等于 ui 隔离完成，而是默认全锁死；权限需显式声明且严格受限，真正隔离需结合 postmessage 与父页状态托管，并优先选用 shadow dom 替代 iframe。
为什么不能只靠 sandbox 属性就认为 UI 隔离完成了
加了 sandbox 不等于“已隔离”，而是“全锁死”——sandbox 或 sandbox="" 会让 iframe 连 HTML 都不解析，Network 显示 net::ERR_BLOCKED_BY_RESPONSE，页面直接白屏。你看到的空白不是加载失败，是浏览器压根没开始解析响应体。
权限必须显式声明，且每个 token 都有严格前提：
-
allow-scripts：JS 能执行，但onclick="..."、javascript:void(0)这类内联 handler 依然失效，必须改用addEventListener -
allow-same-origin：仅当src与父页协议+域名+端口完全一致时才生效；不同源时该 token 被静默忽略，加了也白加 -
allow-forms和allow-popups：不是“功能开关”，而是明确授权表单提交或新窗口打开能力，一旦开启就要承担对应风险
sandbox 权限组合在权限管理系统中容易踩的三个坑
权限管理系统常需嵌入第三方策略配置面板、RBAC 角色编辑器或动态表单渲染器，这些组件往往自带脚本和交互逻辑。此时常见误配如下：
-
sandbox="allow-scripts allow-same-origin"：同源时 iframe 可读写父页localStorage和document.cookie，相当于把权限控制逻辑暴露给不可信内容 -
sandbox="allow-top-navigation"：组件可执行top.location = 'https://malicious.site'，整页跳转钓鱼页面，比 XSS 更直接 -
sandbox="allow-scripts allow-popups allow-forms allow-same-origin"：权限堆砌后，沙箱形同虚设，等价于没加sandbox
真正可控的做法是：从 sandbox="allow-scripts" 起步，每加一个 token 都要回答“这个组件真的需要它吗？有没有替代方案？”
UI 隔离 ≠ 功能隔离，必须配合 postMessage 和父页状态托管
沙箱 iframe 中的 localStorage、sessionStorage、IndexedDB 全部绑定到临时 null origin，刷新即丢，DevTools 的 Application 面板显示为空或 (inactive) 是正常现象。
权限管理 UI 常需保存用户筛选条件、折叠状态、临时编辑草稿——这些不能靠 iframe 自己存，必须由父页统一托管：
- iframe 内通过
window.parent.postMessage({ type: 'save-state', data: {...} }, '*')上报变更 - 父页监听时必须校验
event.origin，不能只依赖allow-same-origin - 敏感操作（如角色删除、权限批量更新）必须由父页发起 API 请求，iframe 仅负责展示和收集参数
更安全的替代路径：Shadow DOM 比 iframe 更适合嵌入可控第三方 UI 组件
如果你嵌入的是 CMS 区块、低代码表单引擎或内部封装的策略卡片这类**同源、可维护、非第三方黑盒**内容，<iframe></iframe> 反而是次选：
- Shadow DOM 提供样式、脚本、DOM 三层原生隔离，无需
sandbox配置，也不受跨域限制 - 父页可通过
customElements.define()注册组件，用<policy-editor></policy-editor>方式嵌入，事件通信更自然 - iframe 在这种场景下反而带来额外负担：无法直接访问其内部 DOM、调试困难、懒加载
loading="lazy"对首屏渲染无益
真正需要 iframe 的，是支付网关、地图 SDK、客服弹窗这类外部黑盒服务——它们不可控，才需要沙箱兜底。而权限管理系统的 UI 组件，多数时候属于“可控但需隔离”，Shadow DOM 才是更轻、更稳、更易调试的选择。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
