唯一可靠的方式是用 sandbox 属性禁用 allow-top-navigation，其他 JS 检测、postMessage 校验、重写 window.top 均为无效补丁；sandbox 必须静态写在 iframe 标签上，且不可含 allow-top-navigation，子页操作 cookie 或 localStorage 也可能绕过拦截。
唯一可靠的方式是用 sandbox 属性禁用 allow-top-navigation，其他 JS 检测、postMessage 校验、重写 window.top 都是补丁，不能替代它。
为什么 window.top !== window.self 检测没用
这段代码只能在子页 JS 能执行的前提下起作用。但攻击者根本不需要让你的脚本跑起来——比如用 srcdoc 注入 HTML，或父页 iframe 已设 sandbox=""（空沙箱），你的 JS 直接被禁，检测就失效了。更现实的问题是：检测必须放在 <head> 最顶部，否则子页 DOM 已渲染、链接已可点击，拦截就晚了。
常见错误现象包括：
- 控制台报
Blocked a frame from accessing a cross-origin frame，其实是跳转已完成、父页 DOM 失效后的连锁反应 - 页面白屏 + 地址栏突变，但控制台无任何报错
- 子页含
if (top !== self) top.location = self.location这类防嵌套代码，父页立刻被劫持
sandbox 属性怎么配才真正生效
sandbox 必须写在 <iframe> 标签上，且不能靠 JS 动态添加（动态设置无效）。关键点是：只要不显式声明 allow-top-navigation 或 allow-top-navigation-by-user-activation，浏览器默认就禁止子页修改 top.location。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
安全配置示例：
- 完全禁止跳转（最严）：
sandbox="allow-scripts allow-same-origin"—— 缺少allow-top-navigation，top.location.href = 'xxx'会静默失败 - 允许内链跳转但不跳出 iframe：
sandbox="allow-scripts allow-same-origin allow-forms" - 需要弹窗（如扫码登录）：
sandbox="allow-scripts allow-same-origin allow-popups"，仍不加allow-top-navigation - 绝对不要写：
sandbox="allow-scripts allow-top-navigation"—— 这等于授权子页任意控制你的整个页面
验证是否生效：打开开发者工具 → 选中 iframe 元素 → 控制台输入 document.querySelector('iframe').sandbox，返回值应为 DOMTokenList，且不含 allow-top-navigation。
子页写 cookie 或 localStorage 导致跳转绕过拦截
这是最容易被忽略的隐蔽路径。比如微信扫码登录场景中，子页（同源）在回调页直接执行 document.cookie = 'token=xxx'，父页的登录状态检测逻辑会立刻感知并跳转，根本等不到 postMessage 拦截逻辑执行。
正确做法：
- 子页只负责「中转」，不操作任何持久化状态（cookie、localStorage、sessionStorage）
- 所有 token、用户状态必须由父页统一接收、校验、存储
- 若需兼容旧逻辑，可在父页监听
storage事件，发现子页写入后主动清空并 reload iframe
即使子页 JS 报错，它仍可能通过 document.write 或 <meta http-equiv="refresh"> 触发跳转 —— 这些行为同样被 sandbox 默认拦截，但前提是 sandbox 属性真实存在且未被覆盖。
