加 sandbox 属性即默认锁死一切：脚本不执行、表单失效、localStorage 报 SecurityError，必须显式添加 allow-scripts 等权限才能逐项放行，且每增一项均扩大攻击面；空 sandbox 或 sandbox="" 等价于全禁用，document.querySelector('iframe').sandbox 返回空列表即证实权限未开启。
加 sandbox 属性不是“开个安全开关”，而是“默认锁死一切”——脚本不执行、表单点不动、localStorage 访问直接报 SecurityError，连 alert(1) 都不会弹。想让它干点事，必须手动一个个放行，且每放一个，攻击面就扩大一分。
为什么加了 sandbox 就白屏或 JS 完全不运行
写成 <iframe sandbox> 或 <iframe sandbox="">，等价于启用全部限制：外部 <script src>、内联 <script>、onclick、onload、javascript:void(0) 全部失效；fetch() 抛错；form 提交静默失败；window.open() 被拦截；localStorage 读写触发 SecurityError。
浏览器不会报错，而是直接丢弃行为。控制台执行 document.querySelector('iframe').sandbox 返回空 DOMTokenList []，就说明权限全关。
-
allow-scripts只解禁 JS 执行权，不恢复内联事件（onclick等）绑定能力 -
srcdoc内容同样受 sandbox 限制，哪怕没网络请求，内联事件也静默失效 - 动态设置
iframe.sandbox = "allow-scripts"无效；必须在 DOM 插入前就写死属性值
allow-scripts 和 allow-same-origin 合用的真实效果与风险
这两个 token 经常一起出现，但不是功能叠加，而是存在强依赖和高风险：
立即学习“前端免费学习笔记（深入）”；
-
allow-same-origin单独写毫无意义：浏览器先校验src是否与父页协议+域名+端口全一致，不同源时该 token 直接被忽略，且不报错 - 只有
allow-scripts allow-same-origin同时存在，且src确实同源时，localStorage、fetch()同源请求、cookie 读写才可能恢复 - 即使满足条件，
window.parent和document依然不可访问——DOM 隔离是 sandbox 的硬边界 -
src="https://third-party.com/widget.html"却硬加allow-same-origin，既得不到权限，又暴露配置疏忽
按场景选最小权限组合，避免堆砌
每个加上的 token 都意味着额外攻击面。别抄模板，看真实需求配：
- 只展示带 JS 的广告/图表：
sandbox="allow-scripts allow-popups"（禁表单、禁存储、禁跳转父页） - 嵌入用户填写的问卷（需提交）：
sandbox="allow-scripts allow-forms allow-popups"（表单走 CORS 提交，不碰allow-same-origin） - 加载同源可信子系统（如
https://yourapp.com/admin.html）：sandbox="allow-scripts allow-same-origin allow-forms"（必须确认 URL 真同源，且服务端返回正确 CORS 头）
生产环境嵌第三方内容时，永远不要加 allow-same-origin。
验证 sandbox 是否真正生效的实操方法
别靠猜测或文档描述，打开开发者工具直接查：
- 选中
iframe元素 → 控制台输入document.querySelector('iframe').sandbox - 返回的是
DOMTokenList对象，其.length > 0才表示 sandbox 已启用 - 返回值是字符串数组，比如
["allow-scripts", "allow-forms"]，就是当前实际生效的权限列表 - 注意：React/Vue 中用
dangerouslySetInnerHTML或v-html渲染iframe时，容易漏掉sandbox属性，导致未受控内容直接执行脚本
真正麻烦的不是配不配，而是配了但没生效、动态插入时漏掉、或误以为 allow-scripts 就能跑通所有交互逻辑——这些才是线上事故最常出的地方。
