referrerpolicy 属性名必须严格小写，首字母小写、p 大写、其余小写；拼写错误（如 referrerpolicy）会被浏览器忽略，退化为默认策略；fetch 的 referrerpolicy 选项同理，且服务端 referrer-policy 响应头优先级更高。
referrerPolicy 属性名必须小写，大小写敏感
HTML 元素上的 referrerPolicy 属性名是**严格小写的**，写成 referrerpolicy、ReferrerPolicy 或 REFERRERPOLICY 都不会被浏览器识别。这不是规范“建议”，而是解析器实际行为：DOM 属性名匹配基于精确字符串比对，且 HTML 标准明确将该属性定义为 referrerPolicy（首字母小写，P 大写，其余小写）。
常见错误现象：
- 写成
<img src="a.jpg" referrerpolicy="no-referrer">→ Chrome/Firefox/Safari 全部忽略，退化为默认策略 - 写成
@#@#@#@#@#@#@#@#@#@0→ 属性存在但不生效，控制台无报错，Referer 照常发送
fetch API 中的 referrerPolicy 参数不区分大小写？不，它也严格小写
fetch() 的 referrerPolicy 选项是 JS 对象键，JS 对象键本身区分大小写，但更关键的是——浏览器实现只认 referrerPolicy 这个拼写。写成 referrerpolicy 或 ReferrerPolicy 会导致该字段被完全忽略，等效于未传此参数，走浏览器默认策略（通常是 no-referrer-when-downgrade）。
实操建议：
- 永远用
referrerPolicy: 'no-referrer'，不要缩写、不要驼峰变体 - 在 TypeScript 项目中，IDE 通常能提示类型错误；但纯 JS 项目里，拼错不会报错，只会静默失效
- 可通过 Network 面板检查请求头：若看到
Referer字段仍存在，且你确信设置了策略，第一反应应检查拼写
不同浏览器对非法值的容忍度差异很小，别心存侥幸
所有主流浏览器（Chrome 120+、Firefox 124+、Safari 17.4+）对 referrerPolicy 的非法值（如 'strict-origin-when-cross-origin' 拼错一个字母、或传入 null）都采取相同策略：**直接忽略该策略，回落到默认行为**。不存在“Chrome 宽松解析而 Safari 报错”的情况。
这意味着：
- 测试时不能只看控制台有没有报错——没报错 ≠ 生效
- 必须通过 DevTools → Network → 点开具体请求 → Headers → Request Headers → 查看是否含
Referer字段，再结合源/目标协议判断是否符合预期 - 例如：从
https://a.comfetchhttps://b.com/api，设referrerPolicy: 'origin'，应看到Referer: https://a.com/；若看到完整路径（如https://a.com/user/123?token=abc），说明策略未生效
服务端设置的 Referrer-Policy 响应头优先级高于 HTML 属性
如果页面本身由服务端返回时已带 Referrer-Policy: no-referrer 响应头，那么该策略会作用于整个页面内所有子资源请求（包括 <img>、<script></script>、fetch() 等），此时 HTML 元素上的 referrerPolicy 属性或 fetch 的参数会被覆盖（仅对同域资源可能部分生效，但行为不一致，不应依赖）。
容易被忽略的关键点：
- 前端开发者常只改 HTML 或 JS，却忘了后端 Nginx/Apache/Node.js 也在发响应头
- CDN 或反向代理层（如 Cloudflare）也可能注入或覆盖该头，需逐层排查
- 最稳妥的做法：前后端约定统一策略，并在浏览器 Network 面板中确认最终生效的是哪一层设置的值
