1. 项目概述一个“操作系统”级别的浏览器扩展最近在折腾浏览器自动化的时候偶然间看到了一个叫extensionOS的项目。第一眼看到这个名字我承认我被“唬”住了。操作系统一个浏览器扩展能叫操作系统这口气也太大了点。但作为一个在自动化领域摸爬滚打了十来年的老手我深知名字越唬人背后的想法可能越有意思。于是我决定深入扒一扒这个由albertocubeddu开源的extensionOS看看它到底是在玩概念还是真的为浏览器扩展开发带来了某种范式上的革新。简单来说extensionOS不是一个真正的操作系统而是一个为浏览器扩展特别是 Chrome/Chromium 系设计的、高度结构化的开发框架和运行时环境。它的核心目标是把开发一个功能复杂、需要管理多个后台任务、前台交互和跨域数据通信的浏览器扩展变得像开发一个轻量级桌面应用一样清晰、模块化和易于维护。你可以把它想象成给浏览器扩展这个“小房间”里装上了一套完整的“水电管线系统”和“智能家居中控”让各种功能脚本、页面、后台服务能够有序、高效、安全地协同工作而不是一堆散乱的电线和开关。它适合谁呢如果你正在或打算开发一个需要同时处理以下场景的扩展那么extensionOS提供的思路和工具就非常值得借鉴复杂的后台常驻任务比如定时抓取数据、监听网络请求、维护本地数据库。多类型前台界面不仅有一个简单的弹出页popup还需要独立的选项页options、内容脚本注入的侧边栏、或者与特定网页深度集成的界面。大量的跨上下文通信后台脚本background、内容脚本content scripts、弹出页、选项页、甚至不同标签页之间需要频繁、结构化地交换数据和指令。需要状态管理和生命周期控制希望扩展的不同部分能共享状态并能优雅地启动、暂停和清理资源。传统的扩展开发我们往往需要手动在manifest.json里配置一堆权限和内容脚本然后用chrome.runtime.sendMessage和chrome.tabs.sendMessage写大量的胶水代码来处理通信状态管理更是东一榔头西一棒子。extensionOS试图用一套更上层的抽象把这些脏活累活封装起来让开发者能更专注于业务逻辑本身。接下来我就结合对项目源码的研读和实际尝试来拆解一下它是如何做到这一点的。2. 核心架构与设计哲学拆解要理解extensionOS不能只看它提供了哪些 API更要理解它背后的一套设计哲学。这套哲学的核心我称之为“进程模型模拟”与“消息总线中枢”。2.1 模拟操作系统进程模型在传统操作系统中进程是资源分配和独立运行的基本单位。extensionOS借鉴了这个概念将扩展内的不同功能单元抽象为一个个“服务”Services或“应用”Apps。每个服务都运行在相对独立的上下文中拥有自己的生命周期初始化、运行、销毁和职责范围。举个例子一个电商比价扩展可能包含以下服务价格监控服务后台常驻定时查询特定商品的价格。页面分析服务作为内容脚本注入到电商网站提取商品信息。数据存储服务管理本地的商品数据库和用户配置。通知推送服务当价格变动时负责生成和显示浏览器通知。在原生扩展开发中这些功能可能都挤在同一个庞大的后台脚本background script里或者通过复杂的消息传递相互耦合。而在extensionOS的范式下每个服务都是一个独立的模块。它们通过框架定义好的方式注册、启动并通过一个中心化的消息系统进行通信而不是直接互相引用或调用。这带来了几个显著好处高内聚低耦合每个服务的代码高度集中只关心自己的业务。修改价格监控逻辑不会意外影响到通知推送。可维护性提升新人接手项目可以很快根据服务划分理解代码结构。可测试性增强服务可以相对独立地进行单元测试因为它们的依赖主要是消息总线更容易被模拟Mock。2.2. 消息总线扩展的“神经系统”如果说服务是器官那么extensionOS的消息系统就是连接它们的神经网络。它建立了一个全局的、类型化的如果使用TypeScript消息发布/订阅机制。在原生开发中通信是点对点且略显繁琐的// 内容脚本发送消息到后台 chrome.runtime.sendMessage({type: extractProduct, data: {...}}, (response) { console.log(response); }); // 后台脚本需要监听所有类型的消息 chrome.runtime.onMessage.addListener((request, sender, sendResponse) { if (request.type extractProduct) { // 处理逻辑 sendResponse({success: true}); } // ... 其他if else });这种方式在消息类型多的时候监听器会变得非常臃肿且难以管理响应和错误。extensionOS的做法是提供一个统一的“消息总线”。服务可以“发布”一个特定主题的消息而其他服务可以“订阅”这个主题来接收并处理。框架内部会处理消息的路由、序列化和传递。这更像一个事件驱动架构。发布者不需要知道谁在处理消息。订阅者只关心自己感兴趣的主题。总线负责确保消息可靠地送达所有订阅者。这种模式将通信逻辑从业务逻辑中解耦出来。服务之间不再直接依赖而是依赖共同约定的消息契约。这对于构建一个由多个松散耦合组件组成的大型扩展至关重要。2.3. 状态管理共享的“全局内存”复杂的扩展通常需要维护一些共享状态比如用户配置、登录凭证、缓存的数据等。这些状态可能被后台服务、弹出页、选项页等多个部分需要。原生开发中我们可能会用chrome.storageAPI 来持久化存储但每次读取都是异步操作且不适合存储频繁变化的临时状态。或者我们会在后台脚本中维护一个全局变量但这又需要一套机制来将状态变化同步到各个前台页面。extensionOS通常会提供一个状态管理方案。它可能是一个基于消息总线的、可观察Observable的状态容器。当一个服务修改了某个状态状态容器会通过消息总线自动通知所有订阅了该状态变化的其他部分如更新UI。这借鉴了现代前端框架如 Redux, Vuex的思想为浏览器扩展带来了响应式的状态管理体验确保了数据在扩展各个部分的一致性。3. 核心模块与实操要点解析了解了设计哲学我们来看看extensionOS具体由哪些核心模块构成以及在实际编码中需要注意什么。由于extensionOS本身可能是一个不断演化的项目以下内容基于其常见的架构模式进行概括。3.1. 服务Service模块功能的核心载体服务是extensionOS中承载核心业务逻辑的单元。创建一个服务通常需要定义一个类并实现特定的生命周期接口。实操示例创建一个简单的日志服务// services/LoggerService.js import { BaseService } from extensionOS; // 假设框架提供了BaseService class LoggerService extends BaseService { // 服务标识必须是唯一的 static serviceName LoggerService; // 初始化生命周期钩子 async onInitialize() { console.log([${this.constructor.serviceName}] 初始化...); this.logLevel INFO; // 初始化内部状态 // 可以在这里订阅其他服务发布的消息 this.messaging.subscribe(USER_ACTION, this.handleUserAction.bind(this)); } // 启动生命周期钩子 async onStart() { console.log([${this.constructor.serviceName}] 启动...); } // 自定义业务方法 log(message, level INFO) { if (this.shouldLog(level)) { const timestamp new Date().toISOString(); console.log([${timestamp}] [${level}] ${message}); // 也可以发布一个日志消息供其他服务如远程上报服务消费 this.messaging.publish(LOG_ENTRY, { timestamp, level, message }); } } // 私有方法 shouldLog(level) { const levels { DEBUG: 0, INFO: 1, WARN: 2, ERROR: 3 }; return levels[level] levels[this.logLevel]; } // 消息处理函数 handleUserAction(data) { this.log(用户操作: ${data.action}, DEBUG); } // 销毁生命周期钩子用于清理资源 async onDestroy() { console.log([${this.constructor.serviceName}] 销毁...); this.messaging.unsubscribe(USER_ACTION, this.handleUserAction); } } export default LoggerService;关键要点与避坑指南生命周期管理onInitialize和onStart的区别很重要。onInitialize通常用于设置初始状态、订阅消息此时其他服务可能还未完全就绪。onStart在所有服务初始化完成后调用适合执行需要依赖其他服务的启动逻辑。务必在onDestroy中取消消息订阅、清除定时器防止内存泄漏。服务依赖避免在服务的构造函数或onInitialize中直接通过名称引用其他服务实例。正确的做法是通过消息总线进行异步通信或者如果框架支持使用一种依赖注入DI机制。直接引用会导致服务间硬耦合违背了架构初衷。错误处理服务中的异步操作如网络请求必须有健壮的错误处理并将错误通过日志服务记录或发布特定的错误消息。一个未捕获的异常可能导致整个服务线程挂起。3.2. 消息系统Messaging System详解消息系统是extensionOS的主动脉。它的实现质量直接决定了扩展的健壮性和开发体验。消息类型设计一个好的实践是定义清晰的消息类型枚举或常量对象而不是到处使用魔法字符串。// constants/messageTypes.js export const MESSAGE_TYPES { DATA_FETCHED: DATA_FETCHED, UI_UPDATE_REQUESTED: UI_UPDATE_REQUESTED, USER_CONFIG_CHANGED: USER_CONFIG_CHANGED, ERROR_OCCURRED: ERROR_OCCURRED, };发布与订阅模式// 在某个服务中发布消息 this.messaging.publish(MESSAGE_TYPES.DATA_FETCHED, { payload: fetchedData, source: PriceMonitorService }); // 在另一个服务或UI组件中订阅消息 this.messaging.subscribe(MESSAGE_TYPES.DATA_FETCHED, (data) { // 处理数据例如更新本地状态或UI this.updatePriceList(data.payload); });高级模式请求-响应RPC风格简单的发布/订阅是单向的。有时我们需要类似函数调用的请求-响应模式。extensionOS的消息系统可能会对此进行封装。// 服务A发送请求并等待响应 try { const result await this.messaging.request(CALCULATE_TAX, { amount: 100, region: US }); console.log(计算结果:, result); } catch (error) { console.error(请求失败:, error); } // 服务B注册请求处理器 this.messaging.registerRequestHandler(CALCULATE_TAX, async (params) { // 执行计算逻辑 const tax await complexTaxCalculation(params.amount, params.region); return { tax }; // 返回结果会自动被解析为请求的响应 });实操心得消息序列化跨上下文如 background 到 content script传递的消息需要能被序列化为 JSON。避免传递函数、DOM 元素或包含循环引用的复杂对象。避免消息风暴高频事件如鼠标移动、滚动不要直接发布为消息应进行防抖debounce或节流throttle处理或者聚合后再发布。调试工具如果框架没有提供可以考虑开发一个简单的“消息监视器”服务订阅所有消息并打印到控制台这对调试复杂的消息流非常有帮助。3.3. 状态管理State Management实践状态管理模块让共享状态变得可预测。其核心通常是单一的数据源Store和修改状态的固定途径如通过 Action 和 Mutation。简化模型示例// store/AppStore.js (简化概念) class AppStore { constructor() { this.state { user: null, preferences: { theme: light, notifications: true }, priceAlerts: [] }; this.listeners []; } // 获取当前状态只读 getState() { return this.state; } // 提交一个变更Action dispatch(action) { switch (action.type) { case USER_LOGIN: this.state.user action.payload; break; case UPDATE_PREFERENCES: this.state.preferences { ...this.state.preferences, ...action.payload }; break; case ADD_ALERT: this.state.priceAlerts.push(action.payload); break; default: console.warn(未知的 Action 类型:, action.type); } // 状态变更后通知所有监听者 this.notifyListeners(); } // 订阅状态变化 subscribe(listener) { this.listeners.push(listener); // 返回取消订阅的函数 return () { this.listeners this.listeners.filter(l l ! listener); }; } notifyListeners() { this.listeners.forEach(listener listener(this.state)); } } // 在服务或UI组件中使用 const store new AppStore(); // 订阅状态变化 const unsubscribe store.subscribe((newState) { console.log(状态更新了:, newState); // 更新UI }); // 发起一个动作来修改状态 store.dispatch({ type: USER_LOGIN, payload: { name: John, id: 123 } }); // 清理时取消订阅 unsubscribe();在扩展中的集成extensionOS框架会将这个 Store 实例与消息总线连接。一个服务通过发布特定的消息如STORE_DISPATCH来触发状态更新Store 处理更新后再通过消息总线发布一个状态已变更的消息如STORE_UPDATED所有关心该状态的UI组件或其他服务会收到通知并做出反应。注意事项状态不可变性在更新嵌套状态时如preferences务必创建新的对象或数组而不是直接修改原对象。这能确保状态变化的检测是准确的也是 React 等框架的最佳实践。状态序列化如果需要将状态持久化到chrome.storage要确保状态树是可序列化的。状态模块化对于大型扩展应该将状态按领域进行模块化拆分而不是全部堆在一个巨大的 Store 里。4. 基于 extensionOS 的扩展开发全流程假设我们要开发一个“智能阅读助手”扩展它能够提取网页文章正文、朗读内容、并保存阅读笔记。我们来走一遍基于extensionOS或类似架构的开发流程。4.1. 项目初始化与结构规划首先使用你喜欢的构建工具如 Webpack, Rollup初始化一个扩展项目。然后规划目录结构这反映了你的架构思想smart-reader-extension/ ├── manifest.json # 扩展清单文件 ├── src/ │ ├── core/ │ │ ├── messaging/ # 消息总线实现 │ │ ├── store/ # 状态管理实现 │ │ └── serviceManager/ # 服务管理器 │ ├── services/ # 核心服务 │ │ ├── ArticleExtractorService.js │ │ ├── TextToSpeechService.js │ │ ├── NoteManagerService.js │ │ └── LoggerService.js │ ├── ui/ # 用户界面 │ │ ├── popup/ # 弹出页 │ │ ├── options/ # 选项页 │ │ └── content-ui/ # 注入页面的UI组件 │ ├── utils/ # 工具函数 │ └── background.js # 扩展主入口初始化 extensionOS 核心 ├── assets/ # 图标等静态资源 └── package.jsonmanifest.json的关键配置{ manifest_version: 3, name: 智能阅读助手, version: 1.0, permissions: [ activeTab, scripting, storage ], host_permissions: [ all_urls ], background: { service_worker: dist/background.js // 构建后的入口文件 }, action: { default_popup: ui/popup/index.html }, options_page: ui/options/index.html, content_scripts: [ { matches: [all_urls], js: [dist/contentScript.js], css: [ui/content-ui/styles.css] } ] }注意Manifest V3 强制使用service_worker作为后台脚本它是不支持DOM的。这意味着你的extensionOS核心和服务必须在不依赖window、document的环境下运行。UI相关的逻辑应放在弹出页、选项页或内容脚本中。4.2. 核心服务实现与串联1. 文章提取服务 (ArticleExtractorService)这个服务运行在内容脚本上下文中或通过scripting.executeScript注入。它订阅“提取文章”的消息。// services/ArticleExtractorService.js class ArticleExtractorService extends BaseService { static serviceName ArticleExtractorService; async onInitialize() { this.messaging.subscribe(EXTRACT_ARTICLE_REQUEST, this.extract.bind(this)); } async extract() { try { // 使用类似 Readability 的算法提取正文 const articleContent this.domExtractor.extract(); // 发布提取完成的消息携带数据 this.messaging.publish(EXTRACT_ARTICLE_RESULT, { success: true, content: articleContent, url: window.location.href }); } catch (error) { this.messaging.publish(EXTRACT_ARTICLE_RESULT, { success: false, error: error.message }); } } }2. 文本转语音服务 (TextToSpeechService)这个服务可以运行在后台Service Worker中使用 Web Speech API。// services/TextToSpeechService.js class TextToSpeechService extends BaseService { static serviceName TextToSpeechService; async onInitialize() { this.synth window.speechSynthesis; // 注意Service Worker 中无 window this.messaging.subscribe(SPEAK_TEXT, this.speak.bind(this)); this.messaging.subscribe(STOP_SPEECH, this.stop.bind(this)); } async speak(data) { if (!this.synth) { // 在 Service Worker 中无法直接使用需通过前台页面代理 this.messaging.publish(SPEECH_PROXY_NEEDED, data); return; } const utterance new SpeechSynthesisUtterance(data.text); utterance.rate data.rate || 1; this.synth.speak(utterance); } stop() { if (this.synth) { this.synth.cancel(); } } }重要避坑点Manifest V3 的 Service Worker 没有window对象因此无法直接使用speechSynthesis这类 Web API。解决方案是让该服务运行在一个隐藏的前台页面offscreen document中或者让弹出页/选项页的UI服务来充当语音合成的代理。这体现了在extensionOS架构下需要仔细规划每个服务的运行上下文。3. 笔记管理服务 (NoteManagerService)这个服务运行在后台负责与chrome.storage交互管理笔记的增删改查。// services/NoteManagerService.js class NoteManagerService extends BaseService { static serviceName NoteManagerService; async onInitialize() { this.messaging.subscribe(SAVE_NOTE, this.saveNote.bind(this)); this.messaging.subscribe(LOAD_NOTES, this.loadNotes.bind(this)); await this.loadNotesFromStorage(); } async saveNote(data) { const note { id: Date.now(), ...data, createdAt: new Date().toISOString() }; this.notes.push(note); await this.persistNotes(); // 保存后发布状态更新消息让UI刷新 this.messaging.publish(NOTES_UPDATED, { notes: this.notes }); } async persistNotes() { await chrome.storage.local.set({ userNotes: this.notes }); } }4. 服务启动与协调 (background.js)这里是扩展的入口负责初始化extensionOS核心注册并启动所有服务。// background.js (Service Worker) import { ServiceManager } from ./core/serviceManager; import { MessagingSystem } from ./core/messaging; import { AppStore } from ./core/store; import LoggerService from ./services/LoggerService; import NoteManagerService from ./services/NoteManagerService; // TextToSpeechService 可能需要运行在 offscreen document 中这里不直接导入 (async function initExtensionOS() { // 1. 初始化核心基础设施 const messaging new MessagingSystem(); const store new AppStore(); // 2. 创建服务管理器并注入依赖 const serviceManager new ServiceManager({ messaging, store }); // 3. 注册服务注意运行环境 serviceManager.register(LoggerService); serviceManager.register(NoteManagerService); // 注册一个前台代理服务来处理需要DOM的API serviceManager.register(OffscreenProxyService); // 4. 启动所有服务 try { await serviceManager.startAll(); console.log(extensionOS 框架及所有服务启动成功。); } catch (error) { console.error(服务启动失败:, error); } })();4.3. 前端UI与服务的通信UI层弹出页、选项页、内容脚本UI不直接包含复杂逻辑它们只是状态的观察者和用户操作的发起者。弹出页组件示例 (React/Vue)// ui/popup/components/ArticleViewer.vue export default { data() { return { articleContent: , isSpeaking: false }; }, created() { // 组件挂载时订阅相关消息 this.unsubscribe window.messaging.subscribe(EXTRACT_ARTICLE_RESULT, (data) { if (data.success) { this.articleContent data.content; } else { alert(提取失败: data.error); } }); window.messaging.subscribe(SPEECH_STARTED, () { this.isSpeaking true; }); window.messaging.subscribe(SPEECH_ENDED, () { this.isSpeaking false; }); }, beforeDestroy() { // 组件销毁时取消订阅防止内存泄漏 this.unsubscribe(); }, methods: { extractArticle() { // 用户点击按钮发布请求消息 window.messaging.publish(EXTRACT_ARTICLE_REQUEST); }, speakArticle() { if (this.articleContent) { window.messaging.publish(SPEAK_TEXT, { text: this.articleContent }); } }, saveNote() { window.messaging.publish(SAVE_NOTE, { title: 网页笔记, content: this.articleContent.substring(0, 200), url: window.location.href }); } } };关键点UI层通过全局可访问的window.messaging对象需要在页面加载时由框架注入与后台服务通信。它只负责渲染和触发动作所有业务逻辑都在服务中。5. 调试、优化与常见问题排查采用extensionOS这类架构调试方式和优化点也与传统扩展有所不同。5.1. 调试技巧服务隔离调试由于服务相对独立你可以单独为某个服务编写测试脚本模拟它收到的消息观察其输出。这比在完整扩展中设置断点更高效。消息流追踪如前所述实现一个DebugMessagingService它订阅所有消息或通配符并将消息的发布者、主题、载荷和时间戳打印到控制台。这能帮你清晰地看到整个扩展内部的数据流动。状态快照在状态管理模块中实现一个“状态导出”功能可以在弹出页中一键将当前整个应用状态以 JSON 格式下载下来方便分析复杂 bug。利用 Chrome DevToolsService Worker 面板调试后台服务。Popup/Options 面板分别调试弹出页和选项页。Content Script 调试在网页的 DevTools 中上下文选择器里能找到你的扩展内容脚本可以打断点。5.2. 性能优化考量服务懒加载不是所有服务都需要在扩展启动时立即初始化。对于某些只在特定场景下使用的服务如截图服务、文件导出服务可以实现按需加载。ServiceManager可以维护一个服务注册表当收到某个特定消息时再去动态初始化并启动对应的服务。消息载荷优化传递大的数据如文章全文、图片数据时考虑使用chrome.runtime.sendMessage的transfer参数如果可能或者将数据存入chrome.storage或IndexedDB然后只传递一个引用键。避免阻塞操作服务中的任何同步或长时间运行的异步操作都会阻塞该服务线程。对于 CPU 密集型任务如解析大型文档考虑使用 Web Worker并通过消息与主服务通信。内存泄漏排查重点检查onDestroy生命周期中是否正确取消了所有消息订阅、清除了定时器和事件监听器。特别是那些在内容脚本中运行的服务随着页面导航旧的服务实例需要被妥善清理。5.3. 常见问题与解决方案实录问题1消息发送了但接收方没反应。排查步骤检查发送时机接收方服务是否已经完成初始化并订阅了该消息在onStart中发送消息比在onInitialize中更安全。检查上下文消息是否跨越了不可直接通信的上下文例如从内容脚本直接发消息到另一个标签页的内容脚本是不行的需要通过后台脚本中转。确保你的消息总线正确处理了不同上下文间的路由。检查消息主题主题字符串是否完全一致大小写敏感建议使用导出的常量。启用调试服务查看消息是否被成功发布到总线上。问题2Service Worker 自动休眠Manifest V3导致服务停止。现象后台定时任务不执行了一段时间后收不到任何消息。解决方案使用 alarms API对于需要精确定时执行的任务使用chrome.alarmsAPI 替代setInterval。Alarm 事件可以唤醒 Service Worker。保持活动状态通过定期调用chrome.runtime.getPlatformInfo()等无害的 API或者与前台页面建立长期连接chrome.runtime.connect可以一定程度上延迟 SW 的休眠但这不是可靠的方法。设计无状态服务接受 SW 会休眠的事实将服务设计为事件驱动和无状态的。每次被唤醒后根据接收到的消息或 Alarm 事件重新计算状态。问题3内容脚本中的服务与页面脚本冲突。现象扩展注入的 JavaScript 影响了原网页的功能或者被网页的 CSP内容安全策略阻止。解决方案隔离命名空间将所有扩展代码包裹在 IIFE (立即调用函数表达式) 中谨慎使用全局变量。Shadow DOM 封装 UI如果在页面上注入 UI 组件使用 Shadow DOM 来隔离样式和 DOM避免污染页面。尊重 CSP避免使用eval()和内联脚本。如果必须注入脚本使用chrome.scripting.executeScript的file属性而非code属性。错误边界在内容脚本服务的顶层添加try...catch防止单个页面的错误导致整个内容脚本崩溃。问题4状态不同步UI显示旧数据。排查步骤检查状态更新消息确保在 Store 状态改变后确实发布了状态更新消息如STORE_UPDATED。检查UI订阅确认UI组件订阅了正确的状态变化消息并且在组件销毁时取消了订阅。检查消息序列化跨上下文传递的状态对象必须是可序列化的。如果状态中包含函数或循环引用消息传递会失败。使用持久化存储作为单一数据源对于关键状态可以考虑以chrome.storage为唯一真相源。Store 从存储中初始化任何更新都先写入存储再更新内存状态并通知UI。这能保证即使扩展重启状态也能恢复。6. 总结与进阶思考经过对extensionOS理念的深入剖析和实践推演我们可以清楚地看到它本质上是一种架构模式和开发范式而非一个必须使用的具体库。它的价值在于为混乱的浏览器扩展开发引入了清晰的结构、明确的边界和高效的通信机制。对于中小型扩展直接使用原生 API 配合一些简单的模块化组织可能就够了。但对于目标是成长为功能强大、长期维护的“超级扩展”而言早期引入这样的架构思想无疑是给未来的代码库上了一道保险。我个人在实践中的体会是最大的挑战不在于实现消息总线或服务管理器这些基础设施而在于如何合理地划分服务的边界。服务拆得太细消息通信开销大管理复杂拆得太粗又回到了大泥球的老路。这需要开发者对业务领域有深刻的理解并在迭代中不断重构和调整。一个实用的建议是从一个最小核心服务开始。先实现一个日志服务和一个最核心的业务服务让它们通过消息通信。随着功能增加当你发现某个服务的代码超过500行或者职责开始模糊时就是考虑将其拆分为两个独立服务的时候了。最后extensionOS的概念也提醒我们浏览器扩展的能力边界正在不断扩展。通过类似操作系统的架构思想来管理这些能力或许是未来复杂扩展开发的必然趋势。无论你是否直接使用某个名为extensionOS的库理解并应用其背后的服务化、消息驱动、状态集中管理的核心思想都将极大地提升你所构建的浏览器扩展的质量、可维护性和开发体验。