iframe sandbox属性默认全禁用，必须显式添加allow-scripts等权限才能执行脚本；空值或仅sandbox=""即彻底禁止alert、fetch、表单提交等所有主动行为，且内联脚本、eval、onclick均无效。
iframe sandbox 属性默认禁用所有脚本，必须显式授权
直接写 <iframe sandbox></iframe> 会彻底禁止 JavaScript 执行、表单提交、插件加载、弹窗、跨域请求等——连 alert() 都不会触发。这不是“限制”，而是“全关”。想运行脚本，必须在 sandbox 属性值里明确加上 allow-scripts。
只加 allow-scripts 仍无法执行内联脚本或 eval
即使写了 sandbox="allow-scripts"，iframe 内的 <script>alert(1)</script>、onclick="alert(1)"、eval("alert(1)") 全部被阻止。这是安全设计：sandbox 模式下，脚本只能通过外链引入（<script src="xxx.js"></script>），且该 JS 文件必须同源或带 CORS 头。
- 错误写法：
<script>console.log('nope')</script>→ 直接静默忽略 - 可行写法：
<script src="https://trusted.example/script.js"></script>→ 需服务端返回Access-Control-Allow-Origin: *或匹配源 -
setTimeout、setInterval、Function constructor等动态执行机制也一律禁用
allow-same-origin 不能和 allow-scripts 同时开，否则绕过沙箱
如果 iframe 的 src 是同源地址（比如 src="./widget.html"），又同时设了 sandbox="allow-scripts allow-same-origin"，浏览器会拒绝渲染，并在控制台报错：Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('file://') does not match the recipient window's origin ('null')（具体错误信息因环境而异，但本质是安全拦截）。这是因为 allow-same-origin 会让 iframe “假装”和父页同源，从而获得读写父文档 DOM 的能力，与 sandbox 设计目标冲突。
- 真要同源交互 → 别用 sandbox，改用 CSP 或其他隔离手段
- 必须用 sandbox + 脚本 → 只能加载跨域外链脚本，且不能读写父页面任何内容
- 若需有限通信 → 用
window.postMessage，且父页必须监听并校验event.origin
常见组合与实际权限对照
单独一个 allow-scripts 最常用，但也最易误判效果。下面几个典型值对应的实际能力差异很关键：
-
sandbox="allow-scripts"→ 可执行外链脚本，不可弹窗、不可发 fetch、不可访问 localStorage、不可读取 parent -
sandbox="allow-scripts allow-popups"→ 支持window.open()，但新开窗口**不继承 sandbox**，它拥有完整权限（除非自己也加 sandbox） -
sandbox="allow-scripts allow-forms"→ 表单可提交，但提交目标必须是同源或允许 CORS，且不会触发页面跳转（target="_blank" 除外） -
sandbox=""（空字符串）→ 等价于sandbox="allow-scripts allow-same-origin allow-forms ..."全关，不是“无限制”
真正难处理的是第三方 widget 加载后又动态插入 script 标签的场景——sandbox 会在解析时就拦截，根本不会让那段 HTML 进入 DOM。这时候得提前约定好只接受外链 JS，或者换用 Web Worker 隔离逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
