rel="noopener"是安全底线，必须与target="_blank"配合使用以强制新页面window.opener为null，防止tabnabbing劫持；rel="noreferrer"则主动清空referer头和document.referrer，影响来源统计但不替代noopener。
rel="noopener" 是安全底线，不是可选项
它唯一作用是让新页面的 window.opener 变成 null，彻底切断 JS 层面对原页面的访问能力。不加这个，攻击者在新页面里执行 window.opener.location.replace() 就能把你原来的页面跳转到钓鱼站——哪怕跨域也成立。
现代浏览器（Chrome 90+、Firefox 85+、Edge 90+、Safari 12.1+）对 target="_blank" 已默认启用 noopener 行为，但这是隐式兜底，不是标准保证。旧版 WebView、某些 Electron 嵌入场景、或自定义渲染器仍可能漏掉。
- 必须和
target="_blank"配合才生效；单独写rel="noopener"在target="_self"上毫无作用 -
window.open(url, "_blank")不受该属性影响，得用window.open(url, "_blank", "noopener=yes")（仅 Chrome/Edge 支持）或手动置空opener - 别依赖
noreferrer替代它：旧版 Safari（≤12.0）中rel="noreferrer"不保证window.opener === null
rel="noreferrer" 是隐私开关，会真实丢数据
它主动清空 HTTP 请求头里的 Referer 字段，同时让 JS 中的 document.referrer 返回空字符串。这不是浏览器“默认不发”，而是你明确告诉它“不准发”。
后果很直接：GA、神策、友盟等统计工具里，点击该链接的流量会归为「直接访问」，而非「引荐来源」。如果你靠 referrer 做渠道归因、AB 测试分流、或跳转后端鉴权（比如校验来源域名），加了就等于主动砍断一环。
- HTTPS 站点间本就只传 origin（不传路径），所以对隐私提升有限；真正敏感的是带 token 或用户 ID 的 URL
-
rel="noreferrer"不等价于noopener，它不能阻止window.opener访问（尤其在老浏览器中） - 如果只想隐藏路径但保留域名，可用
referrerpolicy="no-referrer-when-downgrade"或更细粒度策略
为什么经常一起写，但顺序和组合要小心
常见写法 rel="noopener noreferrer" 是为了兼顾安全与隐私，但它不是“必须组合”。关键看你的实际需求：
- 只要防劫持：至少写
rel="noopener"，noreferrer可省 - 要隐藏来源且接受数据丢失：加
noreferrer，但别指望它防 opener - 顺序不能颠倒：
rel="noreferrer noopener"在部分 CMS 或 Markdown 渲染器中可能只识别第一个值，导致noopener被忽略 - 服务端或富文本输出时最容易漏——用户粘贴链接、评论自动转 a 标签，
target="_blank"常被自动加上，rel却几乎从不补全
真正容易被忽略的不是要不要加，而是加在哪、谁来加
很多团队把 rel="noopener noreferrer" 当成 HTML 模板里的固定后缀批量注入，却没评估过自己是否真需要 noreferrer。当 referrer 是你归因链的关键一环时，加了反而破坏数据闭环。更现实的风险来自 CMS 输出、富文本编辑器、第三方评论组件——它们生成的外链常有 target="_blank"，但 rel 全靠人工补，一漏就是安全隐患。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
