空 sandbox 属性即全锁死：脚本不解析、表单失效、弹窗拦截、localStorage 报错、origin 强制为 "null"；须显式配置如 allow-scripts 等白名单权限，且动态设置无效，必须插入 DOM 前写死。
sandbox 属性不是“加了就安全”，而是“不加等于全关，加错等于开门揖盗”。空值（sandbox 或 sandbox=""）会彻底禁用脚本、表单、弹窗、存储、自动播放等所有主动行为，连 document.write 都直接抛错——这不是加载失败，是浏览器在 DOM 构建前就拦截了内容。
空 sandbox 属性到底禁用了什么
写成 <iframe sandbox> 就等于把 iframe 当作“零权限容器”：HTML 不进 DOM 树、JS 完全不解析、onclick 和 onload 静默失效、window.open() 和 target="_blank" 全被拦截、localStorage 读写直接抛 SecurityError。哪怕 src 指向同域页面，origin 也会被强制设为 "null"，彻底失去同源身份。
验证方式很简单：选中元素后，在控制台执行 document.querySelector('iframe').sandbox，返回空 DOMTokenList [] 就说明没开任何权限。
sandbox="allow-scripts" 是第三方嵌入的最低可行配置
广告、统计 SDK、图表组件等依赖 JS 的第三方内容，至少要加这个 token 才能跑起来。但它只解禁外链脚本（如 <script src="https://trusted.example/sdk.js"></script>），不恢复以下能力：
立即学习“前端免费学习笔记（深入）”；
-
onclick="alert(1)"等内联事件处理器仍被静默忽略 -
<script>console.log('inline')</script>内联 script 标签完全不执行 -
javascript:void(0)链接点击无响应 - 子页面调用
parent.document仍被拒绝，即使同源
如果第三方 HTML 含大量内联绑定，仅加 allow-scripts 不够，需推动对方改用 addEventListener；或临时配合 srcdoc 替代 src 来绕过外部加载风险。
allow-scripts 和 allow-same-origin 合用的真实效果与陷阱
这两个 token 经常被一起写，但它们不是“功能叠加”，而是存在关键依赖关系：
-
allow-same-origin单独出现无效——浏览器会直接忽略它 -
allow-scripts allow-same-origin同时存在时：localStorage可读写、fetch()可发同源请求，但window.parent和document仍不可访问（sandbox 的 DOM 隔离是硬边界） - 如果
src="https://third-party.com/widget.html"却写了allow-same-origin，该 token 被静默丢弃，既没获得权限，又暴露了配置疏忽
生产环境嵌第三方内容时，永远不要加 allow-same-origin；仅限确认 src 是 https://yourdomain.com/xxx（协议+域名+端口全一致）的内部可信页面。
动态设置 sandbox 属性在 Chrome 中无效
通过 JS 修改 iframe.sandbox 属性（比如 el.sandbox = 'allow-scripts'）在 Chromium 内核中会被忽略，控制台可能报 Failed to set the 'sandbox' property on 'HTMLIFrameElement': This property is read-only。沙箱策略只在 iframe 创建并开始加载资源前生效。
正确做法：
- 服务端渲染时直接写死属性：
<iframe sandbox="allow-scripts allow-forms"> - 前端动态插入时，用字符串拼接或
innerHTML设置（注意 XSS），不能先创建空 iframe 再补sandbox
最易被忽略的一点：CSP 的 frame-src 指令必须同步允许目标域名，否则即使 sandbox 配对正确，也会卡在 net::ERR_BLOCKED_BY_RESPONSE。Tauri 等桌面框架还需额外配 JSON 格式 CSP。
