空sandbox属性导致白屏和net::err_blocked_by_response，因浏览器拒收响应体、跳过html解析；必须显式设置如sandbox="allow-scripts"才能启动加载与执行。
空 sandbox 属性会直接导致白屏和 net::ERR_BLOCKED_BY_RESPONSE
写了 sandbox 或 sandbox=""，浏览器不是“启用沙箱”，而是拒收整个响应体：Network 面板显示 net::ERR_BLOCKED_BY_RESPONSE，DOM 树里连 html 标签都没有，控制台静默无报错。这不是加载失败，是解析流程被拦在最底层。验证方式很简单：document.querySelector('iframe').sandbox.length === 0 就说明权限全关。修复只有一条路——把属性值设为明确的 token 组合，至少含 allow-scripts。
allow-scripts 单独启用时，onclick 和 javascript:void(0) 依然失效
allow-scripts 只解禁 JS 引擎执行权（外链脚本、eval()、setTimeout("...")），不恢复 HTML 解析阶段的内联行为绑定能力。这意味着：
-
onclick="doX()"、onload、javascript:void(0)全部静默拦截，且不报错 -
document.write()、同步XMLHttpRequest、window.open()、表单提交、localStorage仍被禁止 - 第三方不可改源码的 HTML（如广告位、用户富文本）若重度依赖内联事件，仅加
allow-scripts不够；不能指望 Safari 旧版的宽松行为，它不可靠
必须把所有交互逻辑移入 <script></script> 块或外部 JS，并用 addEventListener 绑定事件。
多层 iframe 嵌套时 sandbox 不继承，每层必须独立声明
父 iframe 加了 sandbox="allow-scripts"，子 iframe 仍默认全锁死——浏览器不传递沙箱策略。常见错误现象是子 iframe 内报 Blocked a frame with origin "null" from accessing a cross-origin frame，但根源是它自己没配 allow-scripts，而非父层没传权限。
- 子 iframe 若未声明
sandbox，走标准同源策略，可能被 CSP 或跨域拒绝 - 子 iframe 若声明了
sandbox=""，则连 HTML 解析都跳过，彻底空白 - Chrome 117+ 对缺失
allow-scripts但含onload的 iframe 会自动补权，但 Safari 和旧 WebView 不会，行为不一致，不能依赖
allow-same-origin 是高危开关，不同源时被静默忽略
allow-same-origin 单独写毫无意义：浏览器先校验 src 是否与父页协议+域名+端口完全一致，不同源时该 token 直接被忽略，且不报错。只有与 allow-scripts 同时存在、且 src 确实同源时，才可能恢复 localStorage、同源 fetch()、cookie 读写——但 window.parent 和 document 依然不可访问，DOM 隔离是硬边界。
-
src="https://third-party.com/widget.html"却硬加allow-same-origin，既得不到权限，又暴露配置疏忽 - 生产环境嵌第三方内容时，永远不要加
allow-same-origin - SPA 中同源子系统入口（如
https://app.example.com/admin）需确保服务端返回正确Access-Control-Allow-Origin和SameSitecookie 头，否则仍不可用
真正安全的兼容，不是堆砌 allow-scripts allow-same-origin allow-forms，而是按最小必要原则逐层确认：每层 iframe 的 sandbox 值是否显式声明、是否含必要 token、是否遗漏了 srcdoc 或动态插入场景下的 setAttribute 设置时机。这些细节一旦漏掉，沙箱就形同虚设，或者干脆白屏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
