跨域 iframe 无法读取父页面 URL 是因同源策略强制拦截，仅允许 protocol+host+port 完全一致时访问 location 对象；必须用 postMessage 传递参数并严格校验 origin 和 targetOrigin。
跨域 iframe 无法直接读取父页面 URL，任何尝试访问 window.parent.location.href 或 window.top.location.search 的代码都会触发 SecurityError: Blocked a frame with origin ... from accessing a cross-origin frame。这不是 bug，而是浏览器强制执行的同源策略底线。
为什么 window.parent.location 在跨域时会报错
浏览器只允许同源（协议 + 域名 + 端口完全一致）的 iframe 与父页互相访问对方的 window.location 对象。一旦跨域，该对象的全部属性（href、search、pathname 等）均被屏蔽，读取即抛出 SecurityError。这不是延迟或加载问题，是运行时硬拦截。
- 即使父子页仅端口不同（如
http://localhost:3000←→http://localhost:8080），也视为跨域 -
document.referrer不可靠：可能为空、来自上一级跳转（如搜索引擎）、不包含动态参数（如state=abc123） -
window.top.location.href同样受限，多层嵌套（A → B → C）中只要任一环节跨域，信任链就断裂
postMessage 是唯一安全可行的跨域传参方式
父页必须主动将 URL 或所需参数通过 postMessage 发送给子 iframe，子页监听并校验来源后接收。这是 HTML5 规范定义的、浏览器原生支持的跨域通信机制，不绕过安全策略，而是由浏览器代为管控。
- 父页发送时，
targetOrigin必须写死为子页确切的 origin（如'https://child.example.com'），严禁用'*' - 子页接收时，必须严格比对
event.origin === 'https://parent.example.com'，不能用includes()或正则模糊匹配 - 参数应结构化传输（如
{ url: window.location.href, search: window.location.search }），避免拼接字符串解析风险 - 示例（子页监听）：
window.addEventListener('message', function(event) { if (event.origin !== 'https://parent.example.com') return; const data = typeof event.data === 'string' ? JSON.parse(event.data) : event.data; console.log('received parent URL:', data.url); });
同源 iframe 可以直接访问，但要注意时机和挂载位置
当 iframe 与父页同源时，window.parent.location 可读，但仍有两个关键约束：一是必须等 iframe 完全加载完成；二是父页函数需挂载到全局 window 对象上，不能藏在模块作用域或闭包里。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 子页中使用前应确认：
if (window.parent && window.parent.location) { const parentUrl = window.parent.location.href; } - 父页若提供工具函数，必须显式暴露：
// 父页中 window.getParentUrl = () => window.location.href;
- 子页调用：
const url = window.parent.getParentUrl(); // ✅ 可行 // 而不是 window.parent.location.href ❌（虽同源但部分浏览器仍限制 location 访问）
- 注意：某些浏览器（如 Safari）对同源
location属性访问也有额外限制，优先走函数封装更稳妥
明文拼参进 src 是高危操作，应避免
把 token、state 等敏感参数直接写进 <iframe src="child.html?token=xxx">，会导致这些值泄露到服务端 access log、CDN 缓存、浏览器历史记录、HTTP Referer 头，甚至被第三方脚本通过 document.referrer 拦截。
- 临时解决方案：用
srcdoc内联 HTML 并动态注入参数（仅适用于简单子页，且不支持跨域） - 长期方案：统一走
postMessage+ 后端签名校验（如 JWT），子页收到后向自身后端验证再使用 - 绝对不要依赖
document.referrer提取参数 —— 它不是设计用来传参的，只是导航快照
真正难的不是“怎么拿到 URL”，而是“怎么在不破坏安全模型的前提下，让父页可控、可审计、可撤回地把必要信息交到子页手上”。postMessage 的校验逻辑、origin 白名单管理、消息加解密，才是实际项目里最容易漏掉又最要命的部分。
