空 sandbox 属性等于全禁用，即脚本不执行、表单不提交、弹窗拦截、localStorage 报错、fetch 响应体不可读、console.log 静默失效；它将 iframe 视为全新 origin，同源判断失效，必须显式添加 allow-scripts 等权限 token 才能恢复对应能力。
空 sandbox 属性等于全禁用，不是“默认安全”而是“默认瘫痪”
写成 sandbox 或 sandbox="" 会直接切断 iframe 内所有主动行为能力：脚本不执行、表单不提交、window.open() 被拦截、localStorage 报 SecurityError、fetch() 跨域响应体不可读、甚至 console.log 都不会输出。这不是 bug，是设计——它把 iframe 当作一个全新 origin（变成 null），连同源判断都失效。
常见误操作是加了 sandbox 却还指望 JS 能跑、按钮能点、链接能跳，结果白屏或静默失败。浏览器不会报错提示“被沙箱拦了”，只会让一切归零。
- 必须显式添加权限 token 才能恢复对应能力，没有“默认开启项”
- 多个 token 用空格分隔，不是逗号或分号：
sandbox="allow-scripts allow-forms" - 动态通过 JS 设置
iframe.sandbox = "allow-scripts"无效，必须在 DOM 插入前就写死属性值
allow-scripts 单独启用时，JS 能跑但内联事件仍失效
allow-scripts 是最常加也最容易踩坑的权限。它只解禁外部/内嵌 <script></script> 标签和 eval() 类执行，但**不恢复 HTML 内联事件处理器**——onclick="alert(1)"、onload、javascript:void(0) 全部继续被屏蔽。
这是因为内联 handler 属于解析阶段行为，受更底层策略约束。即使开了 allow-scripts，控制台也不会报错，只是绑定完全不生效。
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 正确做法：把逻辑移入外部 JS 或
srcdoc中的<script></script>块，再用addEventListener绑定 - 如果必须兼容第三方无法修改的 HTML（含大量 onclick），仅加
allow-scripts不够，还得试allow-popups（部分浏览器会放宽，但不可靠） -
allow-scripts+allow-same-origin同时存在才可能让 iframe 读写自身localStorage，但前提是 src 确实与父页同源（协议+域名+端口全一致）
allow-same-origin 不是“信任开关”，而是同源校验通过后的“解锁钥匙”
allow-same-origin 单独写毫无意义：浏览器会先检查 iframe 的实际加载地址是否与父页同源，如果不是，这个 token 直接被忽略，且不报任何警告。比如父页是 https://a.com，iframe src 是 https://b.com/widget.html，哪怕你硬加上 allow-same-origin，localStorage 依然不可读，fetch() 同源请求仍被拦。
它真正起作用的场景极窄：仅当 src 是可信内部页面（如 /admin/chart.html），且你确认该路径始终由同域服务返回时，才考虑组合使用。
- 生产环境嵌第三方内容（广告、用户提交 HTML、SaaS widget）时，绝对不要加
allow-same-origin - 加了
allow-scripts allow-same-origin后，iframe 脚本可调用fetch()、读写自身localStorage，但仍无法访问window.parent或document——DOM 隔离是 sandbox 的硬边界，不会因这两个 token 被绕过 - 若需与父页通信，必须用
postMessage()，且父页需严格校验event.origin
组合权限要按最小必要原则，避免堆砌成“假沙箱”
写成 sandbox="allow-scripts allow-same-origin allow-popups allow-forms allow-top-navigation" 几乎等于没沙箱——它放行了脚本、存储、弹窗、表单、顶层跳转，只剩插件和自动播放被关，攻击面极大。真实需求往往只需要其中一两个。
典型安全组合示例：
- 嵌入第三方统计图表（含 JS 和弹窗）：
sandbox="allow-scripts allow-popups"—— 禁表单、禁存储、禁跳转父页 - 嵌入用户反馈表单（需提交 + JS 验证）：
sandbox="allow-scripts allow-forms allow-popups"—— 表单提交走 CORS，不依赖allow-same-origin - 嵌入同域管理子系统（需 localStorage + 表单 + JS）：
sandbox="allow-scripts allow-same-origin allow-forms"—— 必须确保 src 是https://yourdomain.com/xxx，且不能带重定向
最容易被忽略的一点：allow-downloads 和 allow-storage-access-by-user-activation 这类高级权限浏览器支持极不统一（Chrome 95+ 支持前者，后者仅 Chrome/Edge），Firefox/Safari 完全无视。别指望靠它们在沙箱里持久存数据或触发下载——真有这类需求，应由父页接管处理。
