不是。iframe是否独占渲染进程取决于站点隔离策略：跨站iframe强制独立进程，同站iframe默认复用主页面进程，判断依据是location.origin（协议+域名+端口）是否完全相同。

iframe 是否每个都开一个渲染进程？ 不是。Chrome 的 Site Isolation 策略只对跨站 iframe 强制分配独立渲染进程，同站 iframe 默认复用主页面的渲染进程。关键判断依据是 location.origin（协议 + 域名 + 端口）是否完全一致：

• @#@#@#@#@#@#@#@#@#@0 和 @#@#@#@#@#@#@#@#@#@1 → 同站（example.com），共享进程
• @#@#@#@#@#@#@#@#@#@0 和 @#@#@#@#@#@#@#@#@#@3 → 跨站，强制独立进程
• @#@#@#@#@#@#@#@#@#@0 和 @#@#@#@#@#@#@#@#@#@5 → 协议不同 → 跨站 → 独立进程

常见误判是看到多个 <iframe></iframe> 标签就以为开了多个进程——这会导致内存爆炸，Chrome 从不这么做。

如何验证某个 iframe 是否独占渲染进程？ 打开 Chrome 任务管理器（Shift + Esc），观察“进程”列中是否出现带“辅助框架”（Auxiliary Frame）标识的条目：

• 该条目对应的就是跨站 iframe 的独立渲染进程
• 同站 iframe 不会触发新进程，也不会在此列表中单独显示；它只是主渲染进程内部的一个 FrameTreeNode 实例
• 若看到多个“辅助框架”，说明页面嵌入了多个跨站源（如广告、登录框、第三方 SDK）

注意：chrome://process-internals/ 可查看更底层的 FrameTree 结构和进程绑定关系，但需手动匹配 frame_tree_node_id 和 render_process_id。

Electron 中用 iframe 实现多 tab 为什么容易卡死？ Electron 的主窗口是一个单渲染进程环境，所有动态插入的 <iframe></iframe> 共享同一个 WebContents 上下文：

• 任一 iframe 页面崩溃或执行无限循环，整个主窗口卡死
• 这与 Chrome 浏览器里“每个 tab 独立进程”的设计完全相反
• 更麻烦的是：很多现代网站（如 Google、GitHub）通过 X-Frame-Options: DENY 或 Content-Security-Policy: frame-ancestors 'none' 明确禁止被嵌入，直接导致白屏或 ERR_BLOCKED_BY_RESPONSE 错误

替代方案优先级：

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

• 用 BrowserView（推荐）：每个 tab 对应独立 WebContents，真正模拟浏览器多进程行为
• 用 webview（需谨慎）：支持进程隔离，但需手动处理 new-window、console、preload 等生命周期，且 Electron 22+ 已移除部分 API
• 避免纯 <iframe></iframe> 多 tab 架构

为什么不能靠 iframe 数量估算内存占用？ 因为进程复用逻辑和站点边界强相关，单纯数 <iframe src=""></iframe> 标签毫无意义：

• 10 个同站 iframe → 通常只增加少量内存，仍在主渲染进程内
• 3 个跨站 iframe（如 ad.qq.com、login.taobao.com、maps.google.com）→ 至少新增 3 个独立渲染进程，每个含完整 JS 引擎、DOM 树、V8 实例
• 若某跨站 iframe 内又嵌套了另一个跨站 iframe（如广告内嵌第三方追踪脚本），则会触发二级进程隔离

真正影响内存的是跨站边界数量，不是 DOM 节点或 iframe 标签数量。调试时务必以 location.origin 为单位去数，而不是以 HTML 标签为单位。

跨站判定必须精确到协议、域名、端口三者全等，哪怕只差一个 https vs http，就足以触发独立进程——这点在本地开发（@#@#@#@#@#@#@#@#@#@6 vs @#@#@#@#@#@#@#@#@#@7）和测试环境最容易被忽略。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！