referrer-policy 在 gin 中通过 c.header("referrer-policy", "strict-origin-when-cross-origin") 设置，仅对导航类请求生效，fetch/xhr 等不受影响；需注意显式 referrerpolicy 属性、rel="noreferrer"、重定向及 service worker 等绕过场景。
直接在 Gin 中设置 Referrer-Policy 响应头即可生效，无需额外中间件或浏览器 JS 介入——但必须注意它只对**导航类请求（如 a 标签跳转、form 提交、window.location）** 生效，对 fetch / XHR / img 等资源请求默认不继承该策略。
Referrer-Policy 在 Gin 中怎么设
用 c.Header("Referrer-Policy", "no-referrer") 就行，放在任意中间件或 handler 开头即可。Gin 的 Header() 方法底层调用的是 http.ResponseWriter.Header().Set()，完全符合 HTTP 规范。
- 推荐统一在安全中间件里设置，避免每个 handler 重复写
- 值建议选
"strict-origin-when-cross-origin"（平衡隐私与功能），而非一刀切的"no-referrer"—— 后者会让同站跳转也丢失 referrer，影响分析工具统计 - 若前端有 iframe 场景，需配合
Content-Security-Policy: frame-ancestors使用，否则 referrer 控制可能被绕过
为什么有些 referrer 还是泄露了
常见原因不是 Gin 没设对，而是：
-
fetch()或XMLHttpRequest显式设置了referrerPolicy: "no-referrer"，会覆盖响应头策略 - 页面内
<a href="..."></a>加了referrerpolicy="unsafe-url"属性，优先级高于响应头 - 使用了
rel="noreferrer"的链接，会强制清空 referrer（且不可被响应头覆盖） - 服务端重定向（302/301）时，浏览器对重定向目标的 referrer 处理逻辑独立于原始响应头
Referrer-Policy 和其他安全头的协作关系
它和 X-Frame-Options、Content-Security-Policy 是互补关系，不是替代：
-
Referrer-Policy控制「谁能看到我从哪来」 -
Content-Security-Policy: frame-ancestors 'none'控制「谁可以把我嵌进 iframe」 -
Cross-Origin-Opener-Policy: same-origin控制「谁可以和我共享 window 对象」 - 三者同时存在时，浏览器按各自规则分别执行，不存在覆盖或冲突
真正容易被忽略的是：Referrer-Policy 对 Service Worker 缓存的请求无效，如果用了 SW，得在 fetch 事件里手动删掉 request.referrer 或改写 headers。
