浏览器进程模型、站点隔离与导航生命周期

• 各进程的职责边界（UI、渲染、合成、网络、插件）
• 进程间通信（IPC）与崩溃隔离
• 站点隔离下的进程分配模型

多进程架构按职责拆分：Browser 进程（主进程）管理 UI、标签页生命周期、导航与权限；Renderer 进程负责页面 DOM、样式、脚本执行与渲染（每站点/标签页隔离）；GPU 进程处理合成、栅格化与 GPU 加速（硬件故障隔离）；Network 进程承载网络栈（HTTP 请求、DNS、连接池，独立以减小内核漏洞影响与并发阻塞）；Plugin 进程（如 PDF、PPAPI 时代）隔离插件崩溃。价值：崩溃隔离（渲染进程挂掉不影响浏览器）、安全隔离（站点隔离把不同站点放进不同渲染进程）、并行利用多核。IPC 用 Mojo 通道通信（导航、输入、合成帧）；进程分配受内存与硬件能力影响（进程数量上限、内存压力合并进程）。

考察浏览器架构基础：五大进程职责、IPC 与崩溃隔离、站点隔离的进程分配，答案需讲清"为什么拆"与"怎么协同"。

• prefetch 只拉资源 vs prerender 完整渲染
• 预渲染的进程与资源开销
• 触发、激活与取消的时机

prefetch（ ）只把资源（HTML/JS/CSS）缓存进内存，不执行不渲染，命中时仍需现场加载执行；prerender（Speculation Rules 或旧 ）在后台进程/渲染器中完整执行页面（解析、脚本、请求、布局），用户点击时立即呈现，激活几乎是零延迟的"秒开"。差异本质：预渲染以"重复执行全部前端逻辑"换取"激活即用"，代价是 CPU/内存/带宽开销与副作用（埋点、登录态请求重复执行）。Chrome 的 prerender 在独立渲染器进程执行、与当前页面隔离，激活时把预渲染文档"接入"当前标签页（文档生命周期切换，脚本不会重跑，但会触发 prerenderingchange 与 activate）。工程取舍：命中率高的入口（搜索结果、首页）才值得预渲染，并处理副作用（延迟统计上报、避免支付类页面预渲染）。

考察预加载与预渲染的差异：资源缓存 vs 完整执行、进程隔离与激活语义、开销与副作用治理。

• Site Isolation 的进程分配（每站点一个渲染进程）
• 跨域 iframe 的 OOPIF 隔离
• 对性能、内存与开发者调试的影响

Site Isolation 是 Chromium 的安全模型：按"站点"（scheme+eTLD+1）分配渲染进程，跨站文档不共享进程，配合进程沙箱让"内存破坏类漏洞"难以跨站提权（如 Meltdown/Spectre 时代的防御，防数据泄露）。跨域 iframe 因此以 OOPIF（out-of-process iframe）运行在独立渲染进程，通信走代理（frame proxy）与 IPC，同步阻塞调用被禁止。工程取舍：安全性提升（iframe 崩溃/漏洞不拖垮父页面）、但带来性能与内存开销（多进程、跨进程消息延迟）、复杂调试（进程内断点需要目标进程、Chrome DevTools 的 process 切换）、同步 API 限制（跨 OOPIF 无法同步访问 DOM，如 document.getElementById 跨进程不可用）；页面性能指标（如 iframe 的布局、合成）拆到多进程后需要聚合视图。

考察 Site Isolation 的模型与代价：站点级进程隔离防跨站攻击、OOPIF 的通信与调试成本，答案需平衡安全与工程影响。

• Mojo IPC 的通道模型与消息类型
• 高频消息（输入事件、合成帧、存储写入）的瓶颈
• 缓解策略（批量、通道复用、off-thread 化）

Mojo 是 Chromium 的 IPC 框架，主进程与渲染进程间按接口建立消息管道。高并发瓶颈：单通道串行处理（消息排队，主进程忙时渲染进程输入/合成消息延迟）、大消息（DOM 快照、文件数据）拷贝与序列化开销、存储与权限等共享接口的竞争（多个渲染进程同时写 IndexedDB/cache 时主进程或 IO 线程成为热点）、合成帧与输入事件的高频消息放大。缓解：批量与节流（输入事件按帧合并、合成帧用共享内存传位图）、通道分离（把高优先级消息放独立 Mojo 管道避免队头阻塞）、off-thread 化（把存储、网络下沉到独立进程/线程）、共享内存传递大块数据（Buffer 零拷贝）。前端侧的可见影响：大量同步 API（如 XHR 同步、document.cookie 高频读写）会放大 IPC 压力。

考察浏览器 IPC 的性能模型：通道串行、大消息拷贝、共享接口竞争三大瓶颈，答案需给出系统级缓解与前端影响。

• Tab Freeze 的触发条件与影响范围
• 后台节流（timer 节流、渲染暂停、网络限制）
• 对统计埋点、轮询与计时器逻辑的影响

Tab Freeze（冻结）是浏览器对长期后台、高资源占用标签的节能机制：暂停 JS 执行、定时器、渲染与部分网络活动，标签回到前台时恢复；节流则更普遍：后台标签的 setTimeout 最低 1s（密集嵌套节流到 4 分钟级）、requestAnimationFrame 暂停、WebSocket/SSE 消息合并、渲染完全停止。工程影响：基于计时器的心跳/轮询在后台失真（间隔被放大或停止）、埋点统计延迟或丢失（需在 visibilitychange/pagehide 前 flush 并标记）、实时性功能（在线状态、倒计时）要用"时间戳差值"而非累加计数、定时任务应迁移到 Service Worker（不冻结）或依赖服务器推送；恢复前台时做"过期数据同步"而非假设状态连续。前端应监听 visibilitychange 与 pageshow/pagereveal 重新校准。

考察后台生命周期对前端逻辑的影响：冻结与节流的具体范围、计时与埋点的失真、应对策略。

• 内存压力信号与回收优先级（冻结、丢弃、整页回收）
• 回收与恢复的用户可见影响
• 前端的配合：可恢复状态、持久化、内存自查

内存压力（memory pressure，系统内存不足或单进程超限）下浏览器分层回收：优先冻结（tab freezing，保留状态）、进一步丢弃后台标签页（discarding：卸载渲染器进程但保留导航历史与部分状态，恢复时整页重新加载）、极端时回收前台页面的缓存层（BFCache、back-forward cache）。策略依据：后台状态、资源占用、进程数量与恢复成本（可恢复页面优先保留）。前端配合：用 visibilitychange/pageshow 感知被丢弃后的 reload 并恢复用户状态（URL 状态、持久化存储）、重要状态写 sessionStorage/IndexedDB（丢弃后仍可恢复）、避免常驻大内存（内存泄漏、缓存无上限）加速被回收；可用 document.wasDiscarded（旧版）或恢复时的导航类型（reload + persisted 缺失）判断被丢弃；Chrome 提供诊断（chrome://discards）与 API 演进（如 store 持久化请求 navigator.storage.persist 提高保留概率）。

考察内存回收的浏览器行为：冻结/丢弃的分层策略、前端状态恢复配合与持久化优先级。

• Navigation Preload 与 Service Worker 启动的并行化
• Speculation Rules 的 prefetch/prerender 声明
• 两类机制的性能收益与配置

Navigation Preload 解决 Service Worker 引入的"导航延迟"：SW 启动 + fetch 兜底串行会拖慢首字节，开启 navigationPreload.enable() 后浏览器在 SW 启动期间并行发起真实网络请求，SW 内用 event.preloadResponse 直接复用其结果（命中缓存则跳过），把导航延迟从"SW 启动 + 网络"降为"max(启动, 网络)"。Speculation Rules 是声明式预取/预渲染：

考察浏览器级导航优化：Preload 并行化 SW 启动与请求、Speculation Rules 声明式预取预渲染，答案需说明组合价值。

• 崩溃检测（window 'error' 无法覆盖，需专用事件/机制）
• 自动恢复策略（刷新、会话恢复）
• 状态丢失的取舍与持久化

渲染进程崩溃时页面 JS 停止，普通 error 事件捕获不到，检测方式：Chrome 的 pagehide 后仍无 pageshow、document 的 "crash" 事件（部分环境）、Service Worker 侧监听（SW 与渲染进程分离，可通过 message 心跳超时判断）、或 window.onerror 永久静默配合定时器心跳；恢复策略：检测后显示"页面崩溃"页并引导刷新、浏览器本身的"崩溃后恢复"（session restore 重新打开标签）、Service Worker 承载的持久状态可无感重建。状态丢失取舍：崩溃意味着内存态全失，取舍原则——关键状态（草稿、购物车、表单）实时持久化（IndexedDB/sessionStorage，防抖批量写），非关键状态（滚动位置、临时 UI）允许丢失；崩溃恢复后按持久化状态重建并提示用户，避免"假装无痕"。

考察渲染进程崩溃的工程应对：可靠检测（心跳/SW）、恢复策略与状态持久化取舍，答案需覆盖检测到重建的闭环。

• 同进程导航 vs 跨进程导航的判定
• 进程内导航的提交与文档切换
• 与站点隔离的冲突（跨站必须换进程）

进程内导航指新文档在"同一渲染进程"内完成提交的导航：同站同源、进程可复用时（进程内复用规则），浏览器不新建渲染进程，导航通过本地文档切换完成（commit 在进程内执行）；跨站或站点隔离强制时则跨进程：新进程先创建，提交后再销毁旧文档。影响：进程内导航延迟更低（省去进程创建与 IPC 握手）、BFCache 恢复通常也是进程内（若页面仍在进程内）；但它受站点隔离约束——跨站导航必须换进程（即使有复用机会），同站但进程已超限（进程数上限）时也可能被强制合并或拆分。工程影响：前端对"导航"的感知（performance navigation timing 的 type、commit 时刻）在进程内/跨进程间一致，但调试（DevTools target 切换）与崩溃影响范围不同。

考察导航的进程维度：进程内提交的机制与性能优势、站点隔离下的跨进程强制，答案需说明判定与影响。

• 每源连接数限制与 HTTP/1.1 队头阻塞
• 请求优先级（渲染阻塞、图片、延迟加载）
• HTTP/2/3 多路复用与连接池共享

网络进程管理全局网络栈：每源连接池（HTTP/1.1 默认 6 条连接，超过则排队，队头阻塞明显）、连接复用（keep-alive、TLS 会话恢复）、DNS/代理调度。前端工程影响：请求优先级由浏览器按资源类型与渲染依赖调度（渲染阻塞脚本最高、字体/图片低、延迟加载资源更低）——应善用 preload/preconnect 提示让关键资源提前建连，避免无谓的大请求队列；HTTP/1.1 时代需域名分片缓解 6 连接限制，HTTP/2 多路复用共享单连接（不再依赖分片），HTTP/3（QUIC）进一步解决 TCP 队头阻塞；同源大量并发请求仍会排队，需要合并（批量接口）、懒加载与优先级标注（fetch priority）配合。监控：PerformanceResourceTiming 的 connectionStart 等阶段反映连接池等待。

考察网络层的工程认知：连接限制与队头阻塞、资源优先级调度、协议演进的影响与优化手段。

• 预渲染的完成与取消时机
• 激活后对预渲染页面的接管（不再渲染第二份）
• 避免重复执行的工程手段（副作用、资源）

预渲染页面由浏览器在后台渲染器完成，用户点击链接时"激活"（activate）该页面——激活后预渲染文档接管标签页，浏览器不会重新创建页面，因此不会出现"两份渲染"；浪费风险在于"预渲染了用户不点的页面"（CPU/内存/带宽已消耗）以及预渲染期间执行的副作用（统计、广告、请求重复到服务端）。避免浪费的手段：Speculation Rules 按 eagerness 与命中概率配置（conservative 只对明显即将导航的链接预渲染）、限制预渲染数量与资源、用 document.prerendering 判断在预渲染阶段跳过非必要初始化（延迟统计、延迟第三方脚本、跳过弹窗）；页面激活时通过 prerenderingchange 事件补齐"真正用户可见时"才执行的部分，并检查 PerformanceNavigationTiming 的 activationStart。服务端配合：预渲染请求打标（Sec-Purpose: prefetch;prerender）区分真实访问，避免重复计数。

考察预渲染的资源治理：激活接管避免双渲染、命中率控制与副作用延迟执行，答案需覆盖前后端配合。

• content script 的隔离世界（isolated world）模型
• 与页面主世界的通信（消息传递 vs 共享 DOM）
• 进程归属与站点隔离下的扩展执行

content script 运行在"隔离世界"（isolated world）：与页面主世界共享 DOM，但 JS 全局对象、原型与变量完全隔离（不能直接读页面变量，页面也看不到扩展注入的全局），二者通过共享 DOM 与消息传递（chrome.runtime.sendMessage / window.postMessage 桥接）协作。进程边界：content script 属于页面所在渲染进程（站点隔离下页面进程），background service worker 在扩展进程/独立上下文，通过 IPC 通信；跨域 iframe 中 content script 按匹配规则注入各 OOPIF。工程影响：安全隔离防止页面脚本篡改扩展代码、但也带来"双世界"协调成本（需设计安全的通信契约、避免 DOM 数据竞争）；扩展不得同步访问页面内存态，状态同步走消息，且受权限模型约束。

考察扩展的隔离模型：isolated world 的共享 DOM 与隔离全局、消息通信、进程归属，答案需说明边界与协作。

• speculationrules 的配置（source、eagerness、URLs）
• 触发的保守与激进策略
• 取消与资源回收（不再需要的预渲染）

Speculation Rules 通过

考察 Speculation Rules 的落地：eagerness 分层触发、命中率控制、取消与副作用治理，答案需覆盖触发到激活的完整实践。

• document.prerendering 的语义与读取时机
• prerenderingchange 事件与激活时机的判断
• 延迟初始化与统计修正的工程应用

document.prerendering 在预渲染文档中为 true，用于脚本判断"当前是否处于预渲染阶段"，其工程价值：延迟副作用——统计埋点、广告、第三方 SDK、弹窗与登录态检查在预渲染阶段跳过（避免预渲染期间重复计数与用户体验问题），真正激活后（prerenderingchange 事件触发、document.prerendering 变 false）再执行；性能——预渲染阶段可省略非首屏渲染与资源加载；导航统计修正——激活时用 performance.getEntriesByType('navigation')[0].activationStart 校正首屏与 LCP 计时（预渲染阶段的时间不计入用户体验）。实践要点：在 prerenderingchange 监听中做"补齐初始化"，而非依赖加载事件；注意预渲染请求已真实发往服务端（Sec-Purpose 头标记），服务端统计需过滤。

考察预渲染状态的工程应用：prerendering 属性区分阶段、prerenderingchange 补齐初始化、计时修正与服务端过滤。

• Frame Tree 的父子与兄弟结构
• 跨域 iframe 的进程分配与代理通信
• 对脚本访问、事件与渲染的影响

Frame Tree 是页面框架的层级树：顶层窗口为根，iframe 为子节点（可嵌套多层），每帧有独立的 window 与 document。跨域 iframe（Site Isolation）下，跨站帧被分配到独立渲染进程（OOPIF），Frame Tree 仍保持逻辑父子关系，但跨进程的帧之间通过 frame proxy 与 IPC 通信：window.parent/frames 的同步属性访问受限（跨进程不能同步取值）、postMessage 成为唯一可靠的跨帧通信、DOM 访问被禁止。工程影响：事件传播（跨进程合成与分发）、resize 与布局（合成器跨进程）、window 尺寸读取（需消息往返）；调试时 DevTools 按进程组织 target。理解要点：逻辑树不变、物理隔离存在，一切跨域 iframe 交互走异步消息并显式传递数据。

考察 Frame Tree 与进程隔离的关系：逻辑树与物理进程分离、跨进程帧的异步通信约束、工程影响。

• 导航激活的 commit（提交）与析构（旧文档销毁）时序
• 对 hydration（接管预渲染/SSR 文档）的时序影响
• view transitions 跨文档模式的动画衔接

导航激活（activation）分阶段：新文档准备（可能来自预渲染/BFCache/网络）→ commit（新文档成为当前文档）→ 旧文档析构（unload、监听器清理、资源释放）。对 SPA hydration：若新文档是预渲染/SSR 产物，commit 后框架才接管 DOM（hydration），此时 document.prerendering 已变 false，初始化应挂在 prerenderingchange/激活后；SSR 页面的水合与 view transitions 需要"文档已提交但未交互"的窗口完成状态接管。view transitions：跨文档模式（document.startViewTransition 的 MPA 版本或旧版 startViewTransition 对同文档）在导航激活期间执行快照与动画——旧文档的 snapshot 与析构、新文档的绘制衔接决定过渡是否平滑，析构过快或动画期间 DOM 被改会造成闪烁；Astro/Qwik 等多页应用利用跨文档过渡让页面切换带原生动画，需保证过渡期间新旧视图的视觉连续（固定尺寸容器、图片占位）。

考察导航生命周期的前端衔接：commit/析构时序约束 hydration、跨文档 view transitions 的动画衔接与闪烁规避。

• Origin-Agent-Cluster 头的语义与机制
• 站点级进程隔离之外的"源级"细化
• 工程收益与代价（内存、进程数）

Origin-Agent-Cluster（请求头）让同站不同源获得独立代理集群（agent cluster），即在默认的"站点级"隔离之上按"源"细分：开启后该源页面与其 iframe 在进程/线程分配上更独立，避免同站其他源（如 sub.example.com 与 example.com 之间、同站 iframe）共享进程带来的数据面风险与性能干扰。工程价值：强化隔离——同站跨源的文档不共享渲染进程，降低侧信道与状态污染风险；隔离影响——该源获得独立的 JS 代理集群语义（document.domain 设置失效、跨源同站 iframe 的同步访问受限）；代价——进程数增加、内存上升，仅对高价值/高隔离需求的源开启（登录态页面、敏感 iframe），且需在响应头显式声明（HTTP 头，非 JS 可设）。现代实践：配合 COOP/COEP 组成"源隔离"纵深。

考察源级隔离的现代机制：Origin-Agent-Cluster 的请求头声明、与站点隔离的粒度差异、收益与代价。

• navigation entry 的 type 字段（navigate/reload/back_forward/prerender）
• Bfcache 恢复的检测与注意点
• 恢复时的状态处理（计时、监听器、事件）

Bfcache（往返缓存）恢复的页面不重新加载脚本，而是恢复冻结的快照；检测方法：performance.getEntriesByType('navigation')[0].type === 'back_forward'（BFCache 恢复与普通后退都标记为 back_forward），新版配合 Navigation Timing 的 activationStart（>0 表示 bfcache/prerender 激活）精确识别"从缓存恢复"；同时用 pageshow 事件的 persisted 属性（true 表示从 BFCache 恢复）作为事件侧信号。工程价值：恢复场景下计时器与状态已冻结，需要——重新校准计时（用 Date.now 差值与 activationStart 修正统计）、重连被浏览器挂起的资源（WebSocket/SSE 需重连、轮询重启）、恢复播放器状态（视频/动画位置）、重新计算可见性相关逻辑；避免在 pageshow persisted=true 时重复初始化（如重复埋点、重复请求）。配套：unload 监听会禁用 BFCache，需改用 pagehide。

考察 BFCache 恢复的检测与处理：navigation type 与 persisted 双信号、恢复后的状态校准、避免重复初始化。

• OOPIF 的触发条件（跨站 iframe、站点隔离）
• 跨进程 iframe 的通信与行为变化
• 对布局、事件、调试与性能的影响

OOPIF 是 Chromium 在站点隔离下让跨站 iframe 运行在独立渲染进程的机制：每个跨站 frame 有独立渲染器与进程沙箱，通过"frame proxy"与父进程/其他进程通信。行为变化：跨进程帧之间不能同步访问 DOM/JS（postMessage 是标准通道）、window.parent/frames 的属性访问受限（跨进程返回受限值）、事件与输入跨进程分发、合成时跨进程位图传输；性能上多进程并行与隔离换取消息开销与内存增加。工程影响：跨域 iframe 的第三方脚本（广告、SDK）崩溃不再拖垮父页面；onload 时序、resize 传播（iframe 尺寸需跨进程同步）、焦点与滚动联动需注意异步延迟；DevTools 调试需切换到对应进程 target；同源 iframe（站点隔离下同站）可仍共享进程，混合场景（多子域）需按 OOPIF 语义设计通信。

考察 OOPIF 的机制与影响：触发条件、跨进程通信约束、对工程（事件/调试/性能）的影响。

• 跨文档 view transitions 的机制（旧快照→过渡→新文档）
• 与 prerender 激活的衔接（预渲染文档已就绪，过渡零等待）
• MPA 框架（Astro/Qwik）的工程落地

跨文档 view transitions（MPA 场景）在导航期间自动捕获旧文档快照、播放过渡动画并绘制新文档，使页面切换"视觉连续"（元素共享过渡名则产生形变动画）。与 prerender 衔接：Speculation Rules 预渲染的目标页面在激活时已完成加载与首绘，配合 view transitions 可做到"点击→动画过渡→新页面已渲染"的无缝体验，避免传统导航的空白与闪白；工程实现（Astro/Qwik）：约定视图过渡名（view-transition-name）标识共享元素（页头、导航、封面图）、用 View Transitions API 的 ready/finished 钩子控制动画与骨架、对不支持环境优雅降级（默认导航）；注意点：预渲染期间需延迟非必要脚本、跨文档过渡期间避免 DOM 阻塞操作（大同步布局）、服务端渲染与 hydration 要保证过渡完成前关键内容已呈现；用 document.startViewTransition 相关事件（pageswap/pagereveal）做个性化衔接。

考察 MPA 视觉连续性的组合工程：跨文档过渡快照机制、与 prerender 激活的零等待衔接、框架落地与降级。