服务端响应头是唯一有效防护手段，meta标签无效；X-Frame-Options需全大写带连字符并配always参数；CSP frame-ancestors优先且须带单引号、空格分隔、末尾分号；sandbox属性不防被嵌；JS检测不可靠。
必须用服务端响应头，meta 标签完全无效
浏览器在加载 HTML 前就决定是否渲染 iframe，只看 HTTP 响应头，不解析页面里的 <meta http-equiv="X-Frame-Options"> 或 <meta http-equiv="Content-Security-Policy">。Chrome、Firefox、Safari 自 2015 年起已废弃这类写法，写了等于没写。
常见错误是：在 HTML 里加了 meta，用 curl 或 DevTools 查响应头却看不到字段，还以为“配置成功”。真实生效点只在服务端——Nginx、Apache、Express、Next.js 等必须输出对应 header。
-
X-Frame-Options必须拼写全大写、带连字符：X-Frame-Options，写成X-Frame-Option或x-frame-options都被忽略 - Nginx 配置要加
always参数：add_header X-Frame-Options "DENY" always;，否则 304 或 5xx 响应可能漏发 - 如果同时设置了
Content-Security-Policy的frame-ancestors，浏览器会直接忽略X-Frame-Options—— 这是标准行为，不是 bug
Content-Security-Policy 的 frame-ancestors 是首选方案
frame-ancestors 是 W3C 标准，现代浏览器（Chrome 97+、Firefox 95+）优先采用，且支持比 X-Frame-Options 更细粒度的控制，比如指定多个白名单域名。
关键语法细节极易出错：
立即学习“前端免费学习笔记（深入）”；
-
'none'和'self'必须带单引号，写成none或self会解析失败 - 多个来源用空格分隔，不是逗号：
frame-ancestors 'self' https://admin.example.com; - 末尾分号
;不可省略，否则整条 CSP 规则可能被丢弃 -
'self'要求协议、域名、端口三者完全一致；https://a.com和http://a.com视为不同源
示例（Nginx）：add_header Content-Security-Policy "frame-ancestors 'none';";
sandbox 属性不是防“被嵌”，别在自己页面上乱加
给自己的 HTML 页面加 <iframe sandbox> 对防止被别人嵌套毫无作用。因为 sandbox 是 iframe 自身的属性，只约束“它嵌别人时的行为”，而非“别人能不能嵌它”。
真正该用 sandbox 的场景是：你作为内容提供方，允许别人嵌你的 widget（如评论框、支付按钮），但要限制其能力。
- 空值
sandbox=""默认禁用脚本、表单、弹窗、DOM 访问等所有高风险行为 -
allow-scripts单独启用脚本，但会自动移除allow-same-origin，所以即使同源也无法读写父页面 -
allow-same-origin⚠️ 危险：仅当 iframe 与主站同源且绝对可信时才启用，否则绕过同源策略 -
allow-top-navigation允许跳转顶层页面，易被用于钓鱼，生产环境慎用
前端 JS 检测 window.top !== window.self 已不可靠
这个判断在跨域 iframe 下会因权限限制抛出 SecurityError，导致逻辑中断；在同源嵌套下又永远为 false，完全失效。更严重的是，它无法阻止点击劫持——iframe 加载完成、CSS 层叠覆盖后，用户点击早已被重定向，JS 来不及干预。
某些场景下可作辅助提示（如显示遮罩层），但绝不能替代服务端防护：
- 若页面本身允许被嵌入（如设置了
frame-ancestors 'self' https://trusted.com），这段 JS 反而破坏正常业务 - 恶意方只需把 iframe 设为同源（如利用子域名或本地调试环境），检测即被绕过
- 现代浏览器对
top.location = self.location赋值会抛错，不会静默跳转
真正的防线只有一条：服务端响应头必须存在、拼写正确、未被中间件（CDN/WAF/反向代理）覆盖或清除。其他都是补丁，不是根基。
