最可靠的方式是服务端设置x-frame-options或content-security-policy的frame-ancestors响应头；标签自2015年起被主流浏览器废弃，前端js检测易被绕过且不可靠。
最可靠的方式是服务端返回 X-Frame-Options 或 Content-Security-Policy 响应头，前端 JS 检测（如 top !== self）和 <meta> 标签完全不可靠，现代浏览器已忽略后者，前者极易被绕过。
为什么不能用 设置 X-Frame-Options
浏览器明确不支持通过 <meta http-equiv="X-Frame-Options" content="DENY"> 生效。这个写法看似合理，但所有主流浏览器（Chrome、Firefox、Safari、Edge）自 2015 年起就已废弃该机制。它只在极老版本 IE 中起过作用，现在填了也等于没填。
- HTTP 响应头必须由服务端发送，
<meta>是客户端解析阶段行为，安全控制点早已错过 - 攻击者可直接构造 iframe 加载你的 HTML，根本不会触发 meta 解析逻辑
- 即使页面里写了，用 curl -I 或浏览器开发者工具 Network 面板查响应头，也看不到该字段
如何正确配置 X-Frame-Options 响应头
必须在服务端设置，不同环境写法不同，但核心只有三个有效值：DENY、SAMEORIGIN、ALLOW-FROM（后者已废弃，别用）。
- Nginx：在 server 或 location 块中加
add_header X-Frame-Options "DENY" always;；always很关键，否则 304 或错误页可能漏发 - Apache：用
Header always set X-Frame-Options "SAMEORIGIN"，需启用mod_headers - Next.js：在
next.config.js的headers()函数中按路由匹配添加，比如对/admin路由设"DENY"，对/embed设"SAMEORIGIN" - Express：用
res.setHeader('X-Frame-Options', 'DENY')，注意要在res.send()或next()前调用
Content-Security-Policy 的 frame-ancestors 更推荐
frame-ancestors 是 X-Frame-Options 的现代替代方案，优先级更高，且支持多源、通配符等更灵活语法。只要两者都存在，浏览器会忽略 X-Frame-Options。
- 禁用所有嵌套：
Content-Security-Policy: frame-ancestors 'none' - 仅同源：
frame-ancestors 'self' - 允许多个可信域名：
frame-ancestors 'self' https://partner.com https://app.trusted.co - 注意：
frame-src控制的是“你能嵌谁”，不是“谁能嵌你”；防点击劫持必须用frame-ancestors - 如果用了 CSP，就别再配
X-Frame-Options，避免策略冲突或维护混乱
前端 JS 检测 top !== self 为什么危险
这段代码常见但无效：if (top !== self) top.location = self.location;。它在真实攻击场景中基本形同虚设。
- 攻击者可在 iframe 上加
sandbox="allow-scripts allow-same-origin"，再用document.domain或其他方式绕过同源检测 - 用户禁用 JS 后，整段逻辑直接失效，页面照常被嵌入
- 若页面本身需要被合法 iframe 嵌入（如 SSO 登录弹窗、嵌入式仪表盘），这段代码会直接破坏功能
- 现代浏览器对 sandbox iframe 的限制越来越细，JS 层面的“自救”早已不是安全边界
真正起作用的永远是服务端响应头；frame-ancestors 和 X-Frame-Options 不是“可选加固”，而是点击劫持防护的事实标准。遗漏它，等于把页面大门敞开给透明 iframe —— 无论你前端逻辑写得多严密，都挡不住这一层绕过。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
