document.referrer在html编辑器场景中不可靠，因其返回的是浏览器历史栈上一页面url，而非内容真实出处；空值、about:blank、blob:、扩展协议及同源url均需过滤，应改用url参数、剪贴板数据或后端回传source_url溯源。
document.referrer 不能可靠追踪 HTML 编辑器内容的“来源引用页面”，尤其当编辑器运行在单页应用（SPA）内、iframe 中，或用户通过分享链接直接打开时——它返回的往往不是你期望的“内容出处”，而是浏览器历史栈里上一个载入的文档 URL。
为什么 referrer 在编辑器场景下基本不可信
HTML 编辑器（比如基于 contenteditable、iframe 或 Monaco/CodeMirror 渲染的在线编辑页）通常不靠传统跳转加载内容。用户可能：
- 从微信/钉钉点击链接直达编辑页 → iOS 微信常返回空字符串，安卓可能返回
https://servicewechat.com/ - 刷新编辑页或从书签打开 →
document.referrer为空 - 在 Vue/React 编辑器中切换文档标签 → 前端路由不触发重载，
referrer始终是首次进入时的值 - 编辑器用
iframe加载预览或沙盒环境 → 子iframe的referrer默认继承父页，而非真实内容来源
哪些 referrer 值必须过滤掉
即使拿到非空值，也要立刻排除这些伪来源：
-
about:blank（常见于 JS 动态创建窗口或 iframe 后写入内容） -
blob:开头的地址（如 CodeSandbox、StackBlitz 等沙盒环境生成的临时 URL） -
chrome-extension://、moz-extension://（浏览器插件注入的上下文） - 与当前域名相同的 URL（说明是站内导航，不是“外部引用”）
判断逻辑应类似：
const ref = document.referrer.trim();<br>if (!ref || ref.startsWith('about:') || ref.startsWith('blob:') ||<br> ref.startsWith('chrome-extension:') || ref === location.origin ||<br> new URL(ref).origin === location.origin) {<br> // 不视为有效外部引用<br>}
真正能定位“内容来源”的替代方案
想确认某段 HTML 内容是从哪来的，document.referrer 是错的方向。更可行的做法是：
- 服务端在生成编辑页时，把原始来源信息（如分享 ID、文章 slug、CMS 节点路径）作为 URL query 参数传入，例如：
/editor?id=abc123&source=notion-share，前端直接读URLSearchParams - 如果内容来自富文本粘贴，可检查剪贴板数据：
event.clipboardData.getData('text/html')是否含data-source属性或特定注释标记 - 在保存内容时，由后端记录并回传
source_url字段（比如从知乎 API 拉取的文章，带原始链接），前端缓存在sessionStorage或组件 state 中
如果你仍要 fallback 到 referrer，注意两个硬限制
一是它无法区分“谁分享了这个编辑页”和“谁提供了编辑页里的 HTML 内容”——前者是跳转入口，后者才是你真正想追踪的“引用来源”。二是 HTTP Referer 头本身受 Referrer-Policy 控制，现代浏览器默认在跨域请求中会截断或清空该字段，尤其当目标页协议为 HTTPS 而来源页为 HTTP 时，referrer 直接变为空。
真正在意内容溯源，就得让来源方主动带标识（query、header、meta 标签），而不是依赖浏览器被动传递的、已被层层过滤的 referrer 字符串。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
