前端面试：Web Worker、SharedWorker 和 Service Worker 应该如何选择？

题干与适用场景

一个同源数据分析后台有三项互相独立的需求：

1. 在本地解析用户选择的 200 MiB CSV，同时保持输入和渲染流畅；
2. 多个标签页在至少一个标签页仍打开时，复用一条 WebSocket 和内存中的订阅状态；
3. 断网时仍能打开应用壳与最近一次成功报表，并把一次保存请求排队，联网后重试。

请分别在 Dedicated Worker、SharedWorker 和 Service Worker 中作出选择，并说明所有权、生命周期、通信、持久化、取消与失败处理、浏览器兼容降级、安全边界和验证方案。

200 MiB、单条 WebSocket 和离线保存都是面试题设，不是通用产品指标。本题适合资深前端、Web 平台和前端架构岗位。核心能力是浏览器执行模型与 Web 平台选型，因此归为 frontend。

面试官考察点

第一，能否按“谁拥有任务、需要活多久、要影响哪些页面”选型，而不是把所有后台线程都称为 Web Worker。强回答会明确：页面拥有的计算交给 Dedicated Worker；同源多页面共享的短期运行态可交给 SharedWorker；作用域内的网络代理、缓存和事件驱动后台任务交给 Service Worker。

第二，能否区分线程与持久化。Worker 让代码离开主线程，不会自动降低 CPU、内存或 I/O；SharedWorker 的内存状态也不是持久数据；Service Worker 随时可能在事件之间被浏览器终止，待重试操作必须落到 IndexedDB 等持久存储。

第三，能否量化消息传递成本。结构化克隆通常复制数据；ArrayBuffer 可作为 transferable 转移所有权，避免再复制一份，但发送方的 buffer 会被分离。大 CSV 还要考虑分块、进度、背压和取消。

第四，能否给出可运行的降级路径。SharedWorker 在当前最新浏览器已进入 Baseline 2026，但旧设备或部分实现仍可能不支持；Background Sync 仍不是 Baseline。方案不能把正确性绑定到单个可选 API。

第五，能否验证生命周期故障。只在正常页面里点通一次不够；还要覆盖刷新、关闭最后一个标签页、Service Worker 更新、离线重启、重复同步、缓存污染和旧浏览器降级。

回答前需要澄清的问题

• CSV 解析是一次性还是持续发生？ 一次性任务可按需创建一个 Dedicated Worker；持续并发任务要限制 worker 池大小并建立队列，避免每个文件启动一个线程。
• 输入必须整体读入内存吗？ 若解析器支持流式或分块输入，应优先逐块处理；若必须一次转移完整 ArrayBuffer，要为原始字节、解码字符串、解析结果和索引分别预算峰值内存。
• 多个标签页是否严格同源？ SharedWorker 要求协议、主机和端口完全相同。跨子域、嵌入第三方 iframe 或不同端口时，必须重新设计通信边界。
• “复用一条 WebSocket”是优化还是正确性要求？ 若只是减少连接数，可降级为每页一条连接；若服务器只允许单会话，就需要 BroadcastChannel 加领导者选举、租约与脑裂恢复等更严格的后备方案。
• 离线保存允许后台自动重试吗？ 若操作敏感或可能冲突，应恢复页面后让用户确认；若允许自动重试，请求必须有幂等键、持久状态和有界退避。
• 目标浏览器包含哪些旧版本与隐私模式？ 这会决定 SharedWorker、Background Sync、存储配额和 Service Worker 的能力探测与降级范围。

30 秒回答框架

“我先按所有权和生命周期拆三项需求。200 MiB CSV 是当前页面拥有的 CPU 密集任务，用 Dedicated Worker；按块解析并汇报进度，能转移 ArrayBuffer 时用 transferable，取消时发消息或终止 worker。跨同源标签页的一条 WebSocket 用 SharedWorker，各页面通过 MessagePort 订阅；但先做能力探测，降级为 BroadcastChannel 加领导者选举，必要时允许每页连接。离线壳、报表缓存和稍后重试用 Service Worker，因为它能拦截作用域内请求并响应后台事件。队列写入 IndexedDB，请求带幂等键；Background Sync 不可用时，在页面恢复联网或启动时冲刷。最后专门测试关闭最后标签页、离线重启、重复同步和 Service Worker 更新。”

分步骤深入解答

第一步：先用所有权、作用域和生命周期做选择

三个 Worker 都不能直接操作 DOM。Dedicated Worker 和 SharedWorker 适合运行页面需要的 JavaScript 工作；Service Worker 是注册在源与路径上的事件驱动网络代理。它能处理 fetch、缓存、Push 和支持浏览器中的后台同步，却不适合承载必须连续运行数分钟的 CSV 解析。

第二步：用 Dedicated Worker 隔离 200 MiB CSV 解析

页面按需创建 Dedicated Worker，因为任务只服务当前页面。主线程负责选择文件、展示进度和渲染结果；worker 负责解码、词法解析、类型推断和聚合。它没有 DOM 访问权，结果必须通过消息返回。

下面是接口草图，省略了解析器实现和错误类型。chunkBytes 表示 worker 内部按 4 MiB 批次推进，不表示主线程又复制一次数据：

const parser = new Worker(
  new URL("./csv-parser.worker.js", import.meta.url),
  { type: "module" },
);

const jobId = crypto.randomUUID();
const buffer = await file.arrayBuffer();

parser.postMessage(
  { type: "parse", jobId, buffer, chunkBytes: 4 * 1024 * 1024 },
  [buffer],
);

parser.onmessage = ({ data }) => {
  if (data.jobId !== jobId) return;
  if (data.type === "progress") renderProgress(data.rows);
  if (data.type === "done") renderReport(data.summary);
};

cancelButton.onclick = () => {
  parser.postMessage({ type: "cancel", jobId });
};

取消分为协作式与强制式。解析循环在分块边界检查取消标记，可以释放临时对象并返回状态；worker 卡死或解析器不可中断时调用 terminate()，代价是丢失该 worker 中的全部任务。因此持续处理多个文件时不应盲目共用一个没有任务隔离的 worker。

第三步：把消息复制和峰值内存纳入设计

普通 postMessage 使用结构化克隆。按简化假设，200 MiB ArrayBuffer 在发送端和接收端同时保留一份时，仅原始字节就约占 400 MiB；这还不包括 File 的底层存储、字符串解码、行对象、索引和垃圾回收余量。这个数字是题设推导，不是浏览器内存承诺。

把 ArrayBuffer 放入 transfer list 后，内存资源会移动到 worker，发送方 buffer 被分离，可避免这份字节复制。若页面还需要原始数据，就不能在未规划所有权时直接转移。更稳健的方案是从 Blob.stream() 或切片持续发送小块，worker 返回增量统计；主线程限制在途块数量，消费确认后再发送下一块，从而形成背压。

共享内存不是默认捷径。SharedArrayBuffer 需要 cross-origin isolation，并引入原子操作、数据竞争和更严格的安全部署要求。CSV 解析没有证明普通消息与 transferable 已成为瓶颈前，不应增加这层复杂度。

第四步：用 SharedWorker 维护同源多标签页连接

SharedWorker 适合“至少一个同源页面仍连接时，保留一个共享运行实例”的要求。每个标签页连接同名、同 URL 的 worker，并通过自己的 MessagePort 注册订阅。worker 持有 WebSocket、端口集合和内存订阅表，再把服务端消息路由给相关端口。

const socketHub = new SharedWorker(
  new URL("./socket-hub.shared-worker.js", import.meta.url),
  { type: "module", name: "analytics-socket-hub" },
);

socketHub.port.start();
socketHub.port.postMessage({ type: "subscribe", reportId });
socketHub.port.onmessage = ({ data }) => applyLiveUpdate(data);

window.addEventListener("pagehide", () => {
  socketHub.port.postMessage({ type: "disconnect", reportId });
  socketHub.port.close();
});

SharedWorker 只允许精确同源的上下文访问。只要仍有打开页面持有引用，它可以继续存活；最后一个引用关闭后，不能把它当作永久后台服务。连接断开、浏览器退出或 worker 崩溃后，内存订阅表可以消失，因此服务器游标或必须恢复的订阅要落盘或从页面重新声明。

第五步：为 SharedWorker 设计真实降级

先探测 SharedWorker。不支持时，可让各标签页通过 BroadcastChannel 交换心跳和事件，并用 Web Locks 或带过期时间的存储租约选出一个领导者持有 WebSocket。领导者关闭后，其他页面重新竞选；服务端以会话与事件 ID 去重，客户端用单调 epoch 拒绝旧领导者消息，减少脑裂影响。

这套后备方案比 SharedWorker 复杂。如果“单连接”只是成本优化，最简单的正确降级是每个标签页各开一条 WebSocket，并让服务器承担幂等与连接限制。只有服务端硬约束确实要求单连接，才值得实现选举、租约续期、失联检测和故障注入。

第六步：用 Service Worker 处理离线与重试

Service Worker 注册在 origin 与 path scope 上，可拦截受控页面的请求。应用壳适合 cache-first 或带版本的预缓存；最近报表通常适合 network-first：联网时取新响应并更新 Cache Storage，失败时返回最近成功缓存。用户保存的数据队列应放 IndexedDB，而不是 Cache Storage 或 service worker 全局变量。

以下仍是接口草图。生产实现还要限定可缓存 URL、校验响应、管理缓存版本，并把保存请求写入 IndexedDB 后才向用户显示“已排队”：

navigator.serviceWorker.register("/sw.js", { scope: "/" });

// sw.js
self.addEventListener("install", (event) => {
  event.waitUntil(cacheAppShell());
});

self.addEventListener("fetch", (event) => {
  const url = new URL(event.request.url);
  if (url.pathname.startsWith("/reports/")) {
    event.respondWith(networkFirstReport(event.request));
  }
});

self.addEventListener("sync", (event) => {
  if (event.tag === "retry-report-saves") {
    event.waitUntil(flushIndexedDbQueue());
  }
});

Background Sync 只在部分浏览器可用。注册失败或 API 不存在时，页面在 online、启动和回到前台时调用同一队列冲刷逻辑。网络状态事件只能作为重试触发器，成功仍以服务器响应为准。每条保存带幂等键、尝试次数和下一次重试时间；冲突响应进入人工处理，不能无限自动覆盖。

第七步：处理 Service Worker 生命周期和更新

Service Worker 经下载、安装、等待和激活后才控制页面；首次注册后，当前文档通常要重新导航才进入受控状态。新版本可能安装完成后等待旧页面退出。直接 skipWaiting() 与 clients.claim() 会更快接管，但如果旧页面协议与新 worker 不兼容，可能造成版本错配，所以消息和缓存 schema 要带版本。

浏览器可在事件之间终止 worker，再在下个事件到来时重启。event.waitUntil() 只把当前事件关联的 Promise 延长到完成，不提供常驻进程保证。队列、重试次数和幂等键必须持久化；同步处理应能从任意一条记录重新开始，并能安全处理同一请求执行两次。

Service Worker 只能在安全上下文运行，HTTPS 是生产前提，localhost 是本地开发例外。默认 scope 受脚本路径限制。还要核对 CSP 的 worker-src、缓存是否包含用户敏感响应、退出登录时的缓存隔离，以及跨源请求的 CORS 与凭据策略。

第八步：用故障矩阵验证选择

Dedicated Worker 测试 1 MiB、200 MiB、格式错误和取消；记录主线程长任务、输入延迟、解析吞吐、峰值内存和取消后释放时间。对比结构化克隆、transferable 与分块版本，选择实际瓶颈最小的方案。

SharedWorker 测试两个标签页同时订阅、关闭领导页面、关闭最后一个页面、网络抖动、worker 异常和不支持 SharedWorker 的浏览器。验收条件包括服务端实际连接数、消息不重不漏、重连后游标连续，以及降级模式不破坏正确性。

Service Worker 测试首次访问、已受控访问、离线刷新、缓存过期、新版本等待、强制关闭浏览器、重复 sync、存储配额不足和 Background Sync 缺失。保存接口用幂等键验证“至少一次尝试”不会变成重复写入；缓存测试要确认不同用户的数据不会串用。

高质量示范回答

“我会先看任务由谁拥有、需要活多久、是否要代理网络。200 MiB CSV 只服务当前页面，而且是 CPU 密集解析，所以用 Dedicated Worker。主线程只做文件选择和 UI，worker 按块解析、回报进度并在块边界响应取消。普通消息会结构化克隆；如果完整 200 MiB buffer 在两端各一份，题设下仅原始字节就可能约 400 MiB，所以我会测试 transferable，把 ArrayBuffer 所有权移交给 worker，或者直接流式分块并限制在途数量。

跨标签页的一条 WebSocket 用 SharedWorker。所有页面必须精确同源，每页通过 MessagePort 重新声明订阅，worker 只保存可重建的连接与路由状态。它不承担持久化；最后一个页面关闭、浏览器退出或 worker 崩溃后，状态允许丢失。上线前做能力探测。若单连接只是优化，降级为每页连接；若是硬约束，才用 BroadcastChannel 加租约选主，并用 epoch 和事件 ID 处理脑裂与重复。

离线壳、最近报表和稍后保存用 Service Worker。它在 scope 内拦截请求：应用壳做带版本的预缓存，报表做 network-first 和缓存回退。保存先以幂等键写入 IndexedDB，再注册后台同步。Background Sync 不可用时，在页面启动、回前台或联网时调用同一冲刷器。Service Worker 可能在事件间被终止，所以不能把队列放全局变量；每次处理都从持久状态恢复，并用 waitUntil() 关联当前事件。

最后我会分别验收主线程长任务和内存、真实 WebSocket 连接数和断线恢复、离线重启与重复同步，还会测试 Service Worker 更新等待、旧浏览器降级、缓存用户隔离和 HTTPS/CSP 边界。”

常见错误

• 把 Service Worker 当成长时间计算线程 → 浏览器可在事件间或长任务期间终止它 → 页面计算使用 Dedicated Worker，Service Worker 只处理事件驱动网络工作。
• 把 200 MiB 对象直接 postMessage 后不测内存 → 结构化克隆与解析结果可能同时占用大量内存 → 比较 transferable、分块和流式方案，并测峰值。
• 认为开了 worker 就不会卡 → CPU、垃圾回收和消息序列化仍有成本 → 测主线程长任务、吞吐和消息批量大小。
• 把 SharedWorker 内存当成可靠状态 → 最后引用关闭或浏览器退出后状态可消失 → 只存可重建运行态，关键游标和队列持久化。
• 忽略精确同源限制 → 协议、主机或端口不同就不能共享 → 先画清 origin 边界，再决定是否需要服务端协调。
• SharedWorker 不支持时直接复制复杂选主逻辑 → 业务可能只需要正确而非单连接 → 先判断单连接是否硬约束，能接受时降级为每页连接。
• 把离线队列放 Service Worker 全局变量 → worker 重启后任务丢失 → 先写 IndexedDB，再触发可重复执行的冲刷。
• 只依赖 Background Sync → 它仍不是所有主流浏览器都支持的 Baseline 能力 → 增加启动、回前台和联网时的前台重试。
• 更新时无条件强制接管 → 旧页面与新 worker 协议可能不兼容 → 版本化消息、缓存和迁移，再决定是否跳过等待。
• 缓存所有成功响应 → 私有数据可能跨账号残留或被错误复用 → 建立 URL 白名单、用户隔离、退出清理和响应校验。

追问及应对

追问一：CSV 增长到 2 GiB，移动端内存不够怎么办？

不再调用 file.arrayBuffer() 整体读入。用 Blob.stream() 或 slice() 分块，增量解码时保留跨块的半行，worker 只返回聚合结果或列式批次。主线程设置最大在途块和确认机制形成背压；解析器暴露取消点。若业务必须保留所有行，写入 IndexedDB 或分段文件并按需分页，不把完整对象图留在 JS 堆中。还要设设备级上限和明确的拒绝提示。

追问二：产品要求不同子域的页面也只能有一条 WebSocket 怎么办？

SharedWorker 不能跨精确 origin 共享。可把实时连接集中到一个受控 origin，通过受审计的 iframe 与 postMessage 建立跨源消息桥，并严格校验 targetOrigin、来源和消息 schema；或者把单连接协调移到服务端，让各页面保持独立客户端连接。前者增加安全与可用性耦合，后者增加服务端连接数，应根据硬约束选择，不能绕过同源策略。

追问三：SharedWorker 已是 Baseline 2026，还需要降级吗？

需要按产品浏览器矩阵判断。Baseline 2026 表示最新浏览器版本达到新的共同可用范围，不代表旧设备、企业冻结版本、隐私模式和嵌入环境全部支持。能力探测成本很低；降级可先选择每页连接，只有连接数硬约束成立才实现复杂选主。

追问四：Background Sync 可能重复执行保存，怎样保证不重复写？

客户端为业务操作生成稳定幂等键，队列状态至少包含 payload、键、尝试次数和下次重试时间。服务端以用户与幂等键建立唯一约束或结果记录：相同请求再次到达时返回原结果。客户端只有收到确认才删除队列项；超时视为结果未知并重试，不能生成新键。业务版本冲突进入待处理状态，不做静默覆盖。

追问五：新 Service Worker 已安装，但用户一直不关旧页面怎么办？

先把新版本状态通知受控页面，让用户在安全点刷新。若安全修复必须尽快接管，可以使用 skipWaiting() 和 clients.claim()，前提是新旧页面与 worker 的消息协议向后兼容，缓存和 IndexedDB 迁移可重入。发布验证要同时运行旧页面与新 worker 的组合；无法保证兼容时就保留等待阶段，不能只追求立即激活。

追问六：为什么不用 Service Worker 同时复用多标签页 WebSocket？

Service Worker 的生命周期由事件驱动，浏览器可在空闲时终止它；WebSocket 需要持续连接与内存会话，不符合这种运行模型。SharedWorker 在仍有页面引用时更适合持有共享连接。若目标浏览器不支持 SharedWorker且单连接是硬要求，应采用跨页选主或改变服务端架构，而不是依赖 Service Worker 常驻。