rel="noopener" 是安全底线，必须与 target="_blank" 同时使用以防止 opener 劫持；rel="noreferrer" 仅影响 referer 隐私，不提供安全保护；二者应组合为 rel="noopener noreferrer"，且顺序不可颠倒。
rel="noopener" 是安全底线，不是可选项
只要用了 target="_blank"，又没配 rel="noopener"，就等于把原页面的 window.opener 引用直接交给新页面——对方能调用 window.opener.location.replace() 把你页面跳转到钓鱼页，也能清空 DOM、注入脚本，甚至让原页面卡死。这不是理论风险，TikTok 2023 年真实被利用过。
关键点：
-
rel="noopener"必须和target="_blank"同时出现才生效；单独写在target="_self"上完全无效 - 现代 Chrome/Edge 自 2021 年起默认给
target="_blank"补noopener，但 Safari 和 Firefox 不会，不能依赖 - 旧版 Safari（≤12.0）和部分 WebView 中，
rel="noreferrer"不保证window.opener === null，必须显式写noopener -
rel="NOOPENER"或rel="no-opener"写法错误，浏览器直接忽略，必须小写、无连字符、无空格
rel="noreferrer" 是隐私开关，影响 Referer 数据流
rel="noreferrer" 的作用很实在：它会让浏览器不发 Referer 请求头，同时把 document.referrer 设为空字符串。这意味着目标站点收不到你从哪来的 URL，Google Analytics 里这类流量会归为「直接访问」。
但它不解决 opener 劫持问题——在不支持 noopener 的老环境里，只加 noreferrer 仍可能被反向控制。
常见误判：
- 以为
rel="noreferrer"能替代noopener：不能，二者目的不同，无功能重叠 - 在需要渠道归因的场景下盲目加
noreferrer：比如广告投放、AB 测试分流，Referer 就是关键数据源，加了等于主动丢闭环 - HTTPS 站点间本就只传 origin 不传 path，
noreferrer对隐私提升非常有限
组合写 rel="noopener noreferrer" 的实际效果
写成 rel="noopener noreferrer" 是当前最稳妥的通用写法，但得清楚每部分干了什么：
-
noopener是安全强制项：确保window.opener === null，切断 JS 控制链 -
noreferrer是隐私可选项：清空 Referer，但也意味着来源统计失效 - 顺序不能乱：某些 Markdown 渲染器或 CMS 解析器按顺序取第一个合法值，
rel="noreferrer noopener"可能只认noreferrer而忽略noopener - 如果业务强依赖 Referer（如风控跳转判断、合作方来源校验），至少保留
noopener，别为隐私放弃安全
服务端/富文本场景最容易漏掉 rel 属性
用户评论、CMS 后台、Markdown 编辑器自动识别外链时，常会加 target="_blank"，但几乎从不补 rel。这才是真实高危区——人工检查根本覆盖不到。
推荐做法：
- 服务端输出 HTML 前统一正则匹配：
<a>]*target="_blank"[^>]*(?!rel="[^"]*noopener)[^>]*></a>，自动补rel="noopener noreferrer" - 已有
rel="nofollow"的，合并为rel="nofollow noopener noreferrer"，注意空格分隔 - 避免覆盖
rel="stylesheet"或rel="canonical"这类非<a></a>标签的属性 - 前端用
DOMParser做二次清洗是兜底手段，但不如服务端拦截可靠
真正容易被忽略的是：很多团队把 rel="noopener noreferrer" 当成“安全标配”批量注入，却没评估过自己是否真的需要 noreferrer——尤其当 Referer 是你归因链关键一环时，加了反而破坏数据闭环。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
