iframe中发起阻塞同步调用是否会阻塞主页面的调用？

针对「https://parent.com 嵌入跨域 https://imiframe.com iframe」的场景，iframe内部执行的阻塞同步调用是否会阻塞父页面发起的调用流程，取决于浏览器的跨域站点隔离策略、阻塞调用的具体类型，现代浏览器默认配置下，普通JS同步阻塞、同步XHR都不会影响父页面，仅少量浏览器原生同步行为会例外。

场景拆分说明 #

1. 现代浏览器默认开启跨域站点隔离的场景（Chrome 77+、Firefox 74+等默认开启） #

跨域iframe会被分配到完全独立的渲染进程，和父页面的渲染进程互相隔离，各自拥有独立的主线程、JS执行环境：

• 这种情况下，iframe内部任何占满自身主线程的操作（比如死循环、数秒级的同步计算、批量同步DOM操作），都只会卡顿iframe自身页面，父页面的JS执行、按钮交互、发起的网络请求完全不受影响，可正常运行。
• 哪怕iframe里发起同步XHR（即设置async: false的XMLHttpRequest），也只会阻塞iframe自己的主线程，父页面的所有执行流程不受干扰。
• 补充说明：父页面发起的网络请求本身由浏览器独立的网络进程处理，和iframe的渲染进程状态完全无关，哪怕iframe的渲染进程完全卡死，父页面已发出的请求也会正常完成，返回的回调只会在父页面自身的主线程空闲时执行。

2. 未开启站点隔离的场景（旧版本浏览器、同源iframe） #

跨域iframe不会被分配独立进程，会和父页面共享同一个渲染进程的主线程：

• 此时iframe内部的任何同步阻塞调用（JS长任务、同步XHR）都会直接占满共享主线程，直接阻塞父页面的JS执行、事件响应、请求回调执行全流程。
• 额外提醒：同源iframe不管什么配置下，都必然和父页面共享主线程，其同步阻塞调用一定会影响父页面。

唯一的常见例外：浏览器原生同步弹窗 #

哪怕站点隔离正常开启，只要iframe内调用了alert()、confirm()、prompt()这类浏览器自带的同步弹窗，就会触发整个标签页级别的UI阻塞：

• 弹窗会抢占整个标签页的交互焦点，父页面的点击、JS执行都会被卡住，直到弹窗被关闭才能恢复。
• 这类阻塞是浏览器UI层的全局行为，不属于页面JS主线程的阻塞，不受站点隔离的隔离逻辑影响。

内容的提问来源于stack exchange，提问作者Arun Joseph