sandbox 的核心逻辑是默认锁死一切能力，使 iframe 成为受控容器；空 sandbox="" 会强制 origin 为 "null" 并停用脚本引擎，script 标签、事件处理器全部失效。
加 sandbox 不是为了“防住所有攻击”，而是把 iframe 从“自由运行的网页”变成“受控执行的容器”——默认锁死一切能力，脚本连 alert(1) 都执行不了，这才是它防恶意脚本的核心逻辑。
空 sandbox="" 为什么 JS 一概不执行？
浏览器看到 sandbox="" 或仅写 sandbox，就立刻启用最严隔离：origin 被强制设为 "null"，脚本引擎直接停摆，script 标签、onclick、onload 全部静默失效，控制台甚至不报错。
- 这不是 bug，是设计：sandbox 的哲学是“关了才危险”，不是“开了就安全”
- 常见现象：
Uncaught DOMException: Blocked a frame with origin "null" from accessing...或按钮点不动、图表不渲染 - 验证是否生效：在控制台执行
document.querySelector('iframe').sandbox，返回空DOMTokenList就说明全锁死了
allow-scripts 和 allow-same-origin 同时开有多危险？
这两个 token 组合是线上最常误配的高危操作。它表面看只是“允许脚本 + 允许同源”，实际效果却是让 iframe 内脚本获得自身 origin 下的完整存储读写权（localStorage、fetch()），且一旦 src 真实同源（协议+域名+端口全等），就能绕过关键隔离层。
-
allow-same-origin单独存在无效：不同源时浏览器直接忽略，加了也白加 - 若
src="https://third-party.com/widget.html"却硬加allow-same-origin，既得不到权限，又暴露你对来源校验的疏忽 - 即使两者都开，iframe 内脚本仍无法访问
window.parent或document——DOM 隔离是 sandbox 的硬边界，不可绕过 - 生产环境嵌第三方内容时，绝对不要加
allow-same-origin
怎么配才够用又不越界？按场景选最小组合
别堆砌 token，每个空格分隔的值都是显式授权，也是潜在攻击面。真实业务中，绝大多数第三方嵌入根本不需要 allow-same-origin。
- 只展示带 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"（务必确认src地址严格匹配） - 需要跳转整个页面？别用
allow-top-navigation，改用postMessage通知父页，由父页主动跳转
动态插入的 iframe 容易漏掉 sandbox
React/Vue 中用 dangerouslySetInnerHTML 或 v-html 渲染含 iframe 的 HTML 时，常漏掉 sandbox 属性；服务端模板拼接时也可能只写 src 忘了加沙箱。这种“没配”比“配错”更常见，也更危险。
- 检查方式：打开开发者工具 → Elements → 找到 iframe 标签 → 确认是否存在
sandbox属性及具体值 - 补救建议：所有动态生成 iframe 的逻辑，必须显式拼接
sandbox，不能依赖默认或父级继承 - 真正容易被忽略的点是：
sandbox不会继承，不会传播，不会自动生效——它只作用于当前标签，且必须写在 HTML 字符串里
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
