最可靠的方式是通过服务器响应头配置X-Frame-Options或Content-Security-Policy；前端JS检测（如top !== self）和meta标签均不可靠，易被绕过或完全失效，且现代浏览器已忽略meta方式。
直接在服务器响应头里加 X-Frame-Options 或 Content-Security-Policy 是最可靠的方式；前端 JS 检测只能作为辅助，且容易被绕过。
为什么不能只靠 JavaScript 判断 top !== self
这种写法看似简单，但实际防护能力很弱：
- 浏览器禁用 JS 后完全失效
- 攻击者可在 iframe 上设
sandbox="allow-scripts"之外的权限，再用 CSP 或其他手段拦截你的脚本执行 -
document.referrer在跨域、隐私模式、HTTPS→HTTP 场景下为空或不可靠，拿它做白名单校验会误杀或漏防 - 如果页面本身依赖 iframe（比如嵌入地图、视频），这段代码会导致功能异常
Nginx 配置 X-Frame-Options 最简实践
这是兼容性最好、部署最快的方式，适用于静态 index.html 托管场景：
add_header X-Frame-Options "DENY" always; # 或只允许同源：add_header X-Frame-Options "SAMEORIGIN" always;
注意两点：
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 必须加
always参数，否则 Nginx 默认不给 304、4xx 响应加头 -
ALLOW-FROM已被 Chrome/Firefox/Edge 弃用，2026 年起基本无效，别用
用 Content-Security-Policy 替代 X-Frame-Options
现代标准，支持更细粒度控制，且优先级高于 X-Frame-Options：
add_header Content-Security-Policy "frame-ancestors 'self' https://trusted.example.com;" always;
关键细节：
-
'self'表示同源，注意带引号；none表示彻底禁止（等价于DENY） - 多个允许域名用空格分隔，不是逗号
- 如果同时配置了
X-Frame-Options和frame-ancestors，后者生效，前者被忽略
index.html 里加 meta 标签行不行
不行。HTML <meta http-equiv="X-Frame-Options"> 在所有主流浏览器中均被忽略，包括 Chrome 120+、Firefox 125+、Safari 17+。这个写法只在极老版本 IE 中有效，2026 年已无实际意义。
真正起作用的永远是 HTTP 响应头——无论是 Nginx、Apache、CDN 还是 Next.js / Express 等服务端框架，都得从那里配。JS 和 meta 属于“聊胜于无”的补救措施，别当主力。
