直接访问 iframe.contentWindow 报“Blocked a frame with origin”错误即为同源策略硬性拦截，非语法或网络问题；只要协议、域名、端口任一不同，即触发该限制，且无法绕过。
iframe.contentWindow 访问被 Blocked 怎么确认是同源策略拦截
直接报错 Blocked a frame with origin "https://a.com" from accessing a cross-origin frame 就是典型同源策略拦截，不是 JS 语法或网络错误。这种拦截发生在你尝试读取 iframe.contentWindow、iframe.contentDocument 或调用其方法（如 getBoundingClientRect()）时。
关键判断点：
- 检查 iframe 的
src是否与当前页面协议、域名、端口完全一致——只要任一不同，就触发拦截 - 不要依赖控制台是否有“CORS 错误”，CORS 是针对 fetch/XMLHttpRequest 的；iframe 跨域访问 DOM 是另一套限制机制
-
document.domain已废弃，且仅对同主域子域（如a.example.com↔b.example.com）有效，不能用于不同域名间
postMessage 通信失败常见卡点
postMessage 是唯一被浏览器允许的跨域 iframe 通信方式，但极易因细节失效。
排查清单：
立即学习“前端免费学习笔记（深入）”；
- 发送方未等 iframe 加载完成就调用
postMessage()：必须监听iframe.onload或确保嵌入页已触发DOMContentLoaded - 接收方没校验
event.origin：硬编码写成if (event.origin !== 'https://trusted.com') return;，否则任意来源都能伪造消息 - 发送了不可序列化数据：比如函数、DOM 节点、
undefined、Symbol，会静默丢弃，只传 plain object / string / number - 主页面监听在
window上，但嵌入页调用的是parent.postMessage(..., '*')：虽然能发出去，但*会绕过源校验，存在 XSS 风险，应明确指定目标源
为什么嵌入页高度自适应总出错
常见需求是让父页根据嵌入页内容动态调整 iframe.height，但直接读 iframe.contentDocument.body.scrollHeight 几乎必错。
原因和替代方案：
- CSS 干扰：嵌入页若有
height: 100%、position: fixed或 flex 布局，scrollHeight可能返回 0 或固定值 - 时机问题：嵌入页 JS 执行完、图片加载完、字体渲染完，高度才稳定；建议嵌入页在
window.addEventListener('load', ...)后再发 resize 消息 - 防抖缺失：内容频繁重排（如打字、动画）会导致大量重复消息，应在嵌入页加
setTimeout防抖，比如 100ms 内只上报最后一次高度 - 更可靠做法：嵌入页主动计算并上报真实内容高度（例如
document.documentElement.scrollHeight），而非依赖 body
服务端代理中转时容易忽略的响应头
当无法修改目标服务端 CORS 配置，只能走同域中转接口（如 /api/forward?url=https://other.com/data）时，仍可能失败。
注意点：
- 中转接口本身要透传或设置
Access-Control-Allow-Origin，否则前端 fetch 仍被拦截 - 若中转请求带
credentials: 'include'，后端必须返回具体域名（不能是*），且需显式加Access-Control-Allow-Credentials: true - 中转逻辑若用了
fetch或axios，默认不携带 cookie，需设credentials: 'include'并确保目标服务端允许该 origin - 避免在中转层做 JSONP 回退——JSONP 只支持 GET，且服务端必须配合返回 callback 包裹格式，现代项目基本不适用
