• 初阶：
      • 是什么：一种网页嵌套技术，它能够将其它页面，以独立 “浏览器上下文” 方式嵌入当前页面
        • 有自己的单独的 dom 树结构、cssom 结构、独立渲染上下文等完整的浏览器环境
        • 独立浏览器历史栈
        • 有严格隔离的 js、css 安全策略
      • 适用场景：
        • 过去：实现 ajax 请求、form 表单异步提交、SPA、长轮询效果
        • 现在：广告、微前端；其次，鉴于 iframe 简便与兼容性，有不少大网站依然提供了 iframe 嵌入功能，如 youtube、google map 等
    • 中阶：
      • 性能：
        • iframe 会阻塞父页面的 onload 事件，且 iframe dom 节点创建耗时很大，容易导致主页面(onloade)耗时增加
        • iframe 与父页面共享连接池，这意味着同域受请求并发限制影响，互相阻塞
        • iframe 需要完整走打开页面流程：dns、tls、资源请求、资源响应、dom 构建等，此时：
          • 如果资源的缓存策略没设置好，可能增加额外的http请求
          • 需要构建一颗独立的 dom、cssom 树等
        • 更甚的，不同站点的 iframe 运行在一个独立进程，iframe 与主页面之间的通讯基本都是IPC
        • 消耗更多的内存
      • 安全性：iframe 提供了一套严格的安全限制，包括：
        • 通过进程隔离，严格控制两端信息互通
        • 限制主页面与 iframe 之间互相调用接口，例如不能直接修改对方的 dom content
        • sandbox 限制了 iframe 能执行的操作类型，例如限制弹框
        • 通过 csp 限制可执行脚本来源
        • 通过 allow 限制 子页面 特性策略，例如不能调起摄像头等
        • X-Frames-Options 头限制页面可以作用子页面被嵌入哪些页面
      • 其它问题：
        • 丢失可导航性
        • iframe 内容无法被搜索引擎理解
    • 高阶：
      • 不同站点时，out of process iframe 模型：多进程渲染同一个页面，很多能力需要借助 browser 实现
        • 能复用操作系统，进程级别的资源隔离策略来确保安全性
        • iframe 与 主页面 各自有一个 renderer 进程，两者各自控制自己的渲染区域，最终通过 browser 进程合并渲染结果后渲染到屏幕上
        • 交互：browser 需要判断用户交互区域属于那个页面，之后将事件通过 ipc 方式传递给相应 renderer
        • 通讯：
          • iframe 与 主页面，互相持有对方的 window 代理对象， postmessage 或其它交互操作时，消息会先放到 browser 进程，之后再转发到具体进程
          • 同站点之间使用同一个进程，支持同步通讯；不同站点使用不同进程，需要ipc通讯
        • same-site vs same-origin
          • origin：域名、协议、端口
          • site：根域名 + 二级域名相同，认为是同站点
      • 感受：虽然很多文章说iframe不好，但实际上它却一直存活至今，在不同时期被用于解决不同问题，从最开始用于实现 spa，到实现异步数据请求，到现在的安全沙箱，未来 ShadowRealm API 正式发布后，不知道iframe会不会又被用于解决其它问题

    资料：