为什么行内脚本创建共享工作者线程没有意义

行内脚本创建共享工作者线程没有意义。

---

因为每个基于行内脚本字符串创建的Blobd都会被赋予自己唯一的浏览器内部URL，所以行内脚本创建的共享工作者线程始终是唯一的。

---

你的理解基本是正确的，但我们可以更精确地澄清一下其中的机制和原因。

---

背景知识

SharedWorker 是 Web API 的一部分，用于在多个浏览上下文（如多个窗口、iframe 或 Worker）之间共享一个 Worker 实例。要创建 SharedWorker，通常的做法是提供一个指向 JavaScript 文件的 URL：

Js

const sharedWorker = new SharedWorker('worker.js');

所有使用相同 URL 创建的 SharedWorker 实例会共享同一个后台线程。

行内脚本与 Blob URL

当你尝试使用“行内脚本”（即直接在主脚本中定义的字符串代码）来创建 SharedWorker 时，常见的做法是：

Js

const code = `onconnect = function(e) { /* ... */ };`;
const blob = new Blob([code], { type: 'application/javascript' });
const url = URL.createObjectURL(blob);
const sharedWorker = new SharedWorker(url);

这里的关键点在于：每次调用 URL.createObjectURL(new Blob(...)) 都会生成一个唯一的、浏览器内部的 URL（例如 blob:https://example.com/abcd-1234...）。

---

为什么这会导致“没有意义”

• SharedWorker 的共享机制依赖于 URL 的一致性：只有当多个 SharedWorker 构造调用使用完全相同的 URL 时，它们才会连接到同一个共享线程。
• 如果你每次都动态生成一个新的 Blob 并创建新的 Object URL，那么即使脚本内容完全一样，URL 也不同 → 浏览器会认为这是不同的 Worker 脚本 → 创建多个独立的 SharedWorker 实例。
• 因此，无法实现“共享”，失去了 SharedWorker 的核心价值。

---

结论

使用行内脚本通过 Blob URL 创建 SharedWorker 在技术上可行，但由于每次生成的 URL 唯一，导致无法在多个上下文之间真正共享同一个 Worker 实例，因此在实际应用中通常没有意义。

---

补充说明

如果你确实需要动态生成 SharedWorker 脚本并希望多个上下文共享它，可以考虑以下替代方案：

1. 将脚本内容上传到服务器并获取固定 URL（不现实或有安全限制）。
2. 使用 Service Worker 拦截特定路径并动态返回脚本内容（高级技巧，但复杂且可能不可靠）。
3. 改用普通 Worker 或 BroadcastChannel / MessageChannel 等其他通信机制，如果共享线程不是硬性需求。

---

总之，你的观察是准确的：行内脚本 + Blob URL 方式不适合用于创建真正“共享”的 SharedWorker。