空sandbox属性启用全部限制：脚本不执行、表单不提交、弹窗失效、localStorage不可读写，仅postmessage可用；需显式添加allow-scripts等白名单token才能放行对应能力。
空 sandbox 属性会直接禁用所有脚本执行
不加任何值的 sandbox（即 或 ）会让 iframe 进入“全锁死”状态：内联事件（onclick、onload）、<script></script> 标签、javascript:void(0) 链接、eval() 全部失效，且控制台**静默不报错**。这不是 JS 写错了，是权限被硬性拦截。
实操建议：
- 必须显式写
sandbox="allow-scripts"才能运行脚本；只写sandbox就等于关掉一切主动行为 -
allow-scripts不恢复内联事件处理器——哪怕开了它，onclick="alert(1)"依然不触发；正确做法是用addEventListener在外部 JS 或srcdoc中绑定 - 动态设置
iframe.sandbox = "allow-scripts"无效；属性必须在插入 DOM 前就存在
allow-same-origin 和 allow-scripts 同时出现极易越权
allow-same-origin 单独使用无效，浏览器只在 iframe 加载的资源**协议+域名+端口完全匹配父页**时才认它；否则该 token 被直接忽略。但一旦它和 allow-scripts 同时出现，且源确实一致，iframe 就能读写自身 localStorage、发起同源 fetch()，甚至调用 document.write()——但它仍不能访问 window.parent 或修改父页面 DOM，这是 sandbox 的硬隔离边界。
常见踩坑点：
- 给
https://third-party.com/widget.html加sandbox="allow-scripts allow-same-origin"：既得不到同源权限，又暴露了你对来源判断的疏忽 - 生产环境嵌第三方内容时，**绝对不要加
allow-same-origin**；仅限内部可信同源页面（如https://yourdomain.com/admin/） -
allow-same-origin+allow-scripts组合后，localStorage可读写，但cookie仍不可访问（需额外配合SameSite和Secure属性）
表单提交、弹窗、下载等能力需单独放行
默认状态下， 提交点击无反应、window.open() 被拦截、 下载失败——这些不是 bug，是 sandbox 的设计逻辑：每个功能都必须显式授权。
关键 token 实际效果：
-
allow-forms：允许提交，但提交目标仍受 CORS 控制；不加则静默失败，控制台无提示 -
allow-popups：允许window.open()和target="_blank"；建议与allow-scripts搭配使用，否则新开窗口也受限 -
allow-downloads：Chrome 89+ 支持，用于启用；旧版浏览器中即使写了也无效 -
allow-top-navigation-by-user-activation：允许用户点击后跳转顶层页面（如location.href = "..."），比allow-top-navigation安全得多
验证 sandbox 是否生效不能靠猜
别凭现象推测权限是否开启，直接查 DOM 属性最可靠。打开开发者工具，选中 iframe 元素，在 Console 输入：
document.querySelector('iframe').sandbox
返回的是 DOMTokenList，例如 DOMTokenList ["allow-scripts", "allow-forms"]，说明配置已生效；若返回空列表或 DOMTokenList []，说明属性没写对或被覆盖。
容易被忽略的细节：
- 多个 token 必须用**空格分隔**，不是逗号或换行；
sandbox="allow-scripts,allow-forms"是无效写法 -
allow-storage-access-by-user-activation（Chrome/Edge 特有）仅支持用户手势触发的存储访问申请，且无法通过 sandbox 属性直接启用持久化存储 - 即使开了
allow-scripts，XMLHttpRequest同步模式（async: false）仍被禁止；应改用fetch()或异步 XHR
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
