只写sandbox或sandbox=""会直接拒止iframe内容加载，因浏览器拒绝解析响应体，导致空白页及net::err_blocked_by_response错误；必须显式声明如allow-scripts等权限token才能启动加载。
iframe sandbox 属性不加值等于直接拒止，不是隔离
只写 sandbox 或 sandbox="" 不是“开启沙箱”，而是告诉浏览器：禁止解析整个响应体。Network 面板会显示 net::ERR_BLOCKED_BY_RESPONSE，iframe 空白、无 HTML 解析、无 JS 错误、控制台静默——这不是 bug，是规范行为。
真正起效的必须是带明确权限 token 的字符串，例如 sandbox="allow-scripts"。每个 token 是白名单项，不列就不给，写了才开。
-
sandbox（无值）或sandbox=""：禁用脚本、表单、弹窗、storage、cookie、自动播放、top 导航等全部能力 -
sandbox="allow-scripts"：仅解禁脚本执行，origin 仍为null，localStorage和document.cookie仍是隔离空空间 -
sandbox="allow-scripts allow-same-origin"：仅当src确实与父页同源（协议+域名+端口全等）时才生效；不同源时该 token 被浏览器静默忽略
document.cookie 和 localStorage 在沙箱中永远读不到父页数据
即使开了 allow-scripts，沙箱 iframe 的 origin 被强制设为 null，所有存储 API 都绑定到一个临时、匿名、无持久化的上下文里。
典型表现：localStorage.setItem('a', '1') 不报错，但刷新 iframe 后消失；DevTools 的 Application 面板里对应 storage 显示为空或 “(inactive)”；父页完全无法访问该值。
- 这不是兼容性问题，是浏览器设计使然：沙箱目标是隔离，不是模拟同源环境
- 需要持久化状态？必须由父页统一管理，子页仅通过
window.parent.postMessage()上报变更 - 测试时别依赖 DevTools 的 localStorage 标签页，改用控制台直接执行
Object.keys(localStorage)或localStorage.length验证
真正安全的沙箱必须叠加 referrerpolicy、srcdoc 和服务端防护
单独靠 sandbox 属性远远不够。它只管 iframe 内部行为，不管请求泄露、资源加载或被恶意嵌入。
-
referrerpolicy="no-referrer"：防止 iframe 内 fetch 请求携带来源 URL，避免敏感路径泄露 - 优先用
srcdoc替代src：对静态内容（如用户提交的 HTML 片段），直接内联，绕过外部资源加载风险 - 服务端必须设置
X-Frame-Options: DENY或Content-Security-Policy: frame-ancestors 'none'：从源头禁止页面被他人 iframe 嵌入，和 sandbox 形成双向防护 - 若必须用
src，确保目标 URL 是同域或可信 CDN；跨域资源需配合 CORS + CORP 头，否则fetch会被静默拦截
allow-same-origin 是高危配置，多数场景不该用
开发者常误以为加了 allow-same-origin 就能“让 iframe 和父页互通”，实际它只影响存储和 cookie 访问权限，且有硬性前提：src 必须与父页严格同源。更重要的是，即使满足条件，DOM 隔离依然强制存在——window.parent、document.getElementById 等跨 frame 操作仍被 sandbox 拦截。
- 不同源时写
allow-same-origin：浏览器直接忽略，还暴露配置疏漏 - 同源 +
allow-scripts allow-same-origin：可读写父页localStorage和cookie，但无法操作父 DOM，也不能调用window.parent.postMessage（需额外授权） - 更安全的通信方式：始终走
postMessage，并在父页用event.origin严格校验消息来源
沙箱不是开关，是白名单；不是隔离终点，是纵深防御的第一环。最容易被忽略的，是把 sandbox 当成万能锁，却忘了它连网络请求、Referer 泄露、服务端可嵌入性这些基础面都不管。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
