sandbox属性默认启用全部限制，使iframe内脚本无法执行、表单不能提交、无法弹窗或访问存储；需显式添加allow-scripts等白名单权限才能按需开放功能，且每开放一项均增加安全风险。
加 sandbox 不是为了“让 iframe 更安全”，而是为了“不让它干坏事”——它默认锁死一切能力，连 alert(1) 都执行不了；你得亲手一个个开白名单，每开一个，风险就多一分。
为什么一加 sandbox 就白屏或脚本不执行？
因为 sandbox=""（或仅写 sandbox）等价于启用全部限制：脚本被拦截、表单提交静默失败、window.open() 被阻止、localStorage 读写报错、自动播放失效。浏览器甚至把 iframe 的 origin 强制设为 "null"，彻底切断同源判断基础。
- 常见现象：
Uncaught DOMException: Blocked a frame with origin "null" from accessing...或控制台完全没报错但按钮点不动 - 不是 bug，是设计：sandbox 的哲学是“关了才危险”，不是“开了就安全”
- 验证方式：在控制台运行
document.querySelector('iframe').sandbox，返回空DOMTokenList就说明全锁死了
allow-scripts 和 allow-same-origin 同时用有多危险？
allow-scripts 开了 JS 执行权，allow-same-origin 则试图恢复同源身份——但二者合用会绕过关键隔离层，且极易配置失效。
-
allow-same-origin单独存在无效：只有当src确实与父页协议+域名+端口完全一致时，浏览器才认它；否则直接忽略 - 若
src="https://third-party.com/widget.html"却硬加allow-same-origin，既得不到 localStorage 权限，又暴露配置疏忽 - 即使同源且两者都开，iframe 内脚本仍无法访问
window.parent或document——DOM 隔离是 sandbox 的硬边界，不可绕过 - 生产环境嵌第三方内容时，绝对不要加
allow-same-origin
怎么配才够用又不越界？按场景选最小组合
别堆砌 token，每个空格分隔的值都是显式授权，也是潜在攻击面。
- 只展示带 JS 的广告/图表：
sandbox="allow-scripts allow-popups"（禁表单、禁存储、禁跳转） - 嵌入用户可提交的问卷：
sandbox="allow-scripts allow-forms"（表单走 CORS 提交，不碰allow-same-origin） - 加载可信内部子系统（如
https://app.yourdomain.com/admin/）：sandbox="allow-scripts allow-same-origin allow-forms"（确认 URL 严格同源后再开） - 需要跳转整个页面？别用
allow-top-navigation，改用postMessage通知父页，由父页主动跳
容易被忽略的三个真实坑点
很多线上事故不是 sandbox 没配，而是配了但没生效、或动态插入时漏掉了。
- React/Vue 中用
dangerouslySetInnerHTML或v-html渲染 iframe 时，可能漏掉sandbox属性，导致未受控内容直接执行脚本 -
srcdoc内联内容也要加sandbox，否则它绕过 src 加载逻辑，但不受沙箱约束 -
referrerpolicy="no-referrer"和loading="lazy"应和sandbox配合使用，否则 referrer 泄露或首屏加载攻击面仍在
真正难的不是记住所有 token，而是每次加之前问一句：这个 iframe 里跑的是谁的代码？它到底需要哪一项能力？有没有更安全的替代方案（比如用 postMessage 代替 DOM 访问）？
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
