浏览器扩展开发
面向 Manifest V3 打造的 Chrome、Firefox 和 Edge 扩展，由一支真正在 Chrome Web Store 上发布并运营过在线扩展的团队交付。生产力工具、AI 助手、SaaS 伴随式悬浮层、跨浏览器内容工具。架构、MV3 合规、AI 集成、Web Store 提交、上线后的维护。
Chrome 在全球拥有约 38 亿用户(Backlinko / Statcounter,2025)。一款浏览器扩展只需一次点击，即可把您的产品植入用户的会话，没有应用商店的延迟。对比移动端，您要与用户已有的应用争夺主屏幕位置。只要您能做出让用户真心愿意固定在工具栏里的东西，分发问题基本就自动解决了。
为什么浏览器扩展依然值得构建#
38 亿 Chrome 用户，并且仍在增长#
对多数产品类别而言,Web Store 是按活跃用户数衡量的单一最大软件分发渠道。一键安装。您的产品住在浏览器里，出现在每一个页面、每一个标签页。
截至 2024 年,Chrome Web Store 上列有约 112,000 款活跃扩展。其中 86% 用户不足 1,000(Chrome-Stats,2024)。市面上大部分是半成品或分发不力的作品。如果您打算用真正的产品思维来构建，这其实是个好消息。
企业侧数字更有意思：99% 的企业员工安装了至少一款扩展,52% 安装超过十款(LayerX,2025)。以扩展形式交付的 B2B 工具，例如 CRM 悬浮层和销售情报侧边栏，在用户已经投入大部分时间的地方与他们相遇。不需要安装单独的应用、不需要登录重定向，也不用切换上下文。
大多数外包作坊没做对的 Manifest V3 迁移#
Chrome 从 MV2 到 MV3 的转型是扩展生态历史上最大的平台变化。常驻后台页被替换为 Service Worker。内容安全策略(CSP)更严格。远程代码执行被彻底禁止。网络请求修改改由声明式规则重构。截至 2025 年 8 月,73.4% 的 Chrome 扩展已完成迁移；仍在 MV2 上的全部在 Chrome 138/139 中被禁用(Chrome for Developers,2025)。
许多开发外包作坊仍在写 MV2 风格的代码，因为那是他们的文档和内部知识所覆盖的内容。我们的代码库自相关 API 稳定以来就是 MV3 原生的。Service Worker 生命周期管理、替代常驻后台页的存储模式、离线状态处理。没有把旧模式硬塞进新运行时的兼容补丁。
AI 扩展在 2026 年走向何方#
AI 浏览器扩展市场 2023 年估值 15 亿美元，预计到 2031 年达到 78 亿美元（市场研究,2024)。原因很直白：一个能够看到当前页面内容和用户刚刚高亮选中内容的 AI 模型，能给出的答案，远比一个坐在另一个标签页里、什么上下文都没有的聊天机器人要好得多。
难点在于管道。从扩展发起的 LLM API 调用会撞上 CORS 限制。API 密钥不能放在内容脚本里，因为任何安装了该扩展的人都能从安装包里轻易提取出来。用户期望亚秒级响应。打造 GlanceAI 意味着在一个有真实用户反馈 bug 的上线产品上，逐一解决这些约束。
我们做什么#
生产力与工作流工具#
标签页管理器、专注工具、表单自动化、键盘快捷键系统、页面批注。这类扩展安静地住在浏览器里，为您每天重复五十次的动作省下十秒钟。架构上通常比较简单。有生命力的那些，是真正有人思考过工作流、而不是简单包一层 API 的作品。
AI 阅读与研究助手#
这正是 GlanceAI 所在的类别。总结页面、提取关键信息、辅助写作、在用户浏览时从知识库中浮现上下文。LLM 调用通过后端代理进行，绝不在扩展包中直接暴露 API 密钥。上下文捕获通过内容脚本完成；回复在不破坏页面的前提下渲染到侧边栏或悬浮层。
内容工具与 DOM 级定制#
有时您需要修改别家网站。隐藏元素、重新排版、注入自定义 UI,或在既有 Web 应用上加装功能。真正难的不是修改本身，而是隔离。您的内容脚本执行上下文与页面的 JavaScript 环境需要保持干净的分离。激进管理自身 DOM 的页面（大多数现代 SPA)会和您较劲，如果边界不够严密就会出问题。
SaaS 伴随式扩展与 CRM 悬浮层#
想象一下，当有人访问潜在客户的 LinkedIn 资料时，弹出的 CRM 侧边栏。或者一款支持工具从 URL 识别客户并拉出其工单历史。这些 B2B 扩展把您产品的数据呈现在用户正在看的内容旁边。它们需要经过鉴权的 API 集成、在 chrome.storage 中安全存储 Token,以及能在浏览器重启后依然保留、不让用户被登出的会话管理。
跨浏览器扩展(Chrome、Firefox、Edge)#
基于 WebExtensions API 标准构建，可从同一代码库分发到三大浏览器。浏览器特定的兼容层处理权限、存储 API 和 Service Worker 支持上的差异。所有内容在提交前都会在三个平台上测试。
我们怎么构建#
Manifest V3 架构与 Service Worker#
MV3 的 Service Worker 取代了常驻后台页。它是事件驱动的，浏览器可以在它空闲时随时终止。这一改动打破了许多假设。过去住在内存里的一切，如今都需要显式持久化。长时任务要么加保活机制，要么完全挪到后端。
Service Worker 层必须考虑自己的“可死亡性”。为在 Worker 休眠时到达的消息做队列。用 chrome.storage 保存任何需要在重启后仍然存在的内容。基于 Alarm 的定时调度处理周期任务。任何一项没做到，您就会得到一个在开发环境里工作良好、但在生产中因 Chrome 判定 Worker 空闲太久而默默丢消息的扩展。
内容脚本、后台 Worker 和侧边栏#
内容脚本注入到页面上下文。它们能读取和修改 DOM,但运行在隔离的 JavaScript 环境中。侧边栏 API(Chrome 114+)提供一块不覆盖页面的持久化 UI。后台 Service Worker 处理 API 调用、存储和跨标签页通信。
映射很关键。内容脚本处理页面交互。Service Worker 处理状态和 API。侧边栏承担持久化 UI。弹出窗口承担快速交互。如果架构错了，扩展会在浏览器更新时悄无声息地失灵。调试一个在无法访问的页面上默默失败的 Service Worker,并试图复现用户报告的问题，并不是一个愉快的下午。
跨域与权限策略#
过度授权的扩展会被 Web Store 团队更严格地审核，也会让用户在安装时产生戒心。主机权限、内容脚本匹配项和可选权限都应缩到真正完成工作所需的最小集。
从内容脚本发起的跨域 API 调用会被 CORS 拦截。这些调用需要走 Service Worker 的 fetch,或者经由后端代理。这需要在架构阶段就决定，而不是等 QA 中出现 CORS 错误、再让人重构整条调用链。
在扩展中进行 AI 和 LLM 集成#
把 API 密钥放在扩展包里是行不通的。任何安装了扩展的人都能把它提取出来。AI 调用走一个扩展向其鉴权的后端代理。这意味着在扩展之外还需要构建一个后端服务、一套 Token 颁发机制，以及带用量跟踪的限流。
端侧推理现在也是一种选项。Chrome 内置的 Gemini Nano API(Chrome 127+,Prompt API)适用于您希望离线运行、降低延迟或不希望用户数据离开设备的应用场景。使用端侧 AI、远程 API,还是两者兼备，是一个取决于应用场景的产品决策。
基于 WebExtensions API 的跨浏览器兼容#
WebExtensions API 为 Chrome、Firefox 和 Edge 提供了共同的接口面，但实现之间的差异如果您不在三款浏览器上测试就会咬到您。Firefox 使用 browser.*,原生支持 Promise。Chrome 使用 chrome.*,基于回调(MV3 中还附带 Promise 包装）。存储行为不同。Service Worker 支持不同。侧边栏可用性不同。一层 Polyfill 加上一些浏览器特定的条件分支能处理大部分情况；测试构建会在各个目标上验证。
从代码到 Chrome Web Store：完整生命周期#
Web Store 提交与审核#
首次提交到 Chrome Web Store 时会进行人工审核。请求敏感权限（所有 URL 的主机权限、identity API、tabs API)的扩展会被更严格地审查。MV3 中禁止远程代码执行。如果扩展触及用户数据，必须提供隐私政策。
扩展被拒通常是因为权限范围看起来比扩展实际要做的事更大、缺失隐私政策、商店截图存在内容政策违规或代码被混淆。对照开发者项目政策的审计时机在提交之前。拒审邮件并不会附带有用的反馈。
GlanceAI 在走到 24,700+ 用户的路上，反复经历过这一流程。每一次版本更新都要再走一次审核。一边管理这条流水线，一边回应成千上万安装用户的反馈，让我们很清楚 Web Store 流程会在哪里卡住人。
变现：免费增值、订阅和一次性购买模式#
“免费基础版+鉴权门后的高级分层”是最常见的模式。免费层驱动安装；订阅转化深度用户。通过 Stripe 或 Paddle 的一次性付款，适合对购买方有清晰即时价值的实用扩展。面向 B2B 的企业授权通过直销进行，适用于买家可以算出 ROI 的场景。
计费、权益校验和用户账户基础设施要放进初始架构。给已经上线的扩展改装付款模型很痛苦。它通常意味着重写鉴权，有时还要重写 Service Worker 的状态模型。
上线后的迭代和版本管理#
当新版本上架 Web Store 后,Chrome 会自动更新已安装的扩展，通常在一天到三天内完成。Firefox 和 Edge 有类似机制。上线后的维护意味着跟进 Chrome API 的变化（它们确实会破坏现有代码）、处理用户反馈，并为每次更新再走一次审核。
有意愿持续迭代的客户可以选择保留费支持。完整的交接文档也是每个项目的一部分，您的团队随时可以接手。
GlanceAI：我们已经交付的产品#
GlanceAI 是我们内部打造并发布的一款 Chrome 扩展。一款 AI 浏览助手，在没有任何付费获客的情况下，通过 Web Store 自然增长达到 24,700+ 活跃用户。从第一天起就是 MV3、LLM 通过后端代理集成、免费增值模式。
我们谈它不是因为用户数。而是因为构建一款真实扩展暴露了本页描述的所有问题：Service Worker 在最糟糕的时刻死掉、因权限范围被 Web Store 拒审、与 LLM 代理之间的 CORS 问题、用户使用的 Chrome 版本与我们测试版本表现不同。大多数自称做浏览器扩展的团队，并没有向一个足够大的用户群体交付过产品，去暴露这些问题。
完整故事参见 GlanceAI 项目页面。
一个项目长什么样#
发现与界定范围#
我们以一次需求会议开场：扩展需要做什么、面向哪些浏览器、在哪类页面上交互、后端依赖、变现模式、分发计划。
这会转化为一份架构文档，覆盖 Service Worker 结构、内容脚本注入模式、权限清单、若涉及 AI 或鉴权则包含的后端需求，以及带时间线的功能范围。
构建与 QA#
两周一冲刺。每个冲刺边界交付一个可用于测试的开发构建。按适用情况在 Chrome、Firefox 和 Edge 上进行跨浏览器测试。QA 覆盖安装/卸载生命周期、Service Worker 重启行为、目标 URL 上的内容脚本注入、存储持久化，以及扩展所支持的具体用户流程。
对于带内容脚本的扩展，脚本注入不能感知得到地拖慢页面加载。API 调用延迟会被测量并在提交前压下去。
发布与交接#
Web Store 列表素材（截图、推广图、描述文案）作为上线包的一部分准备好。首次提交审核以及审核团队提出的任何政策问题都在上线前处理。
交接内容：完整代码库、部署凭证、开发者面板访问，以及覆盖架构、更新流程和维护程序的文档。
常见问题#
构建一款定制浏览器扩展的费用是多少？
简单的单浏览器、无后端扩展在 3,000 到 8,000 美元之间。加上鉴权、API 集成和跨浏览器支持，则在 8,000 到 18,000 美元之间。带后端代理、变现和完整 Web Store 发布的 AI 扩展在 18,000 至 35,000+ 美元之间。范围差来自真实的架构差异，不是加价。
Manifest V3 是什么，它为什么对 Chrome 扩展重要？
MV3 是 Chrome 当前的扩展平台规范。它将常驻后台页替换为短暂的 Service Worker、禁止远程代码执行，并重构了网络请求修改的方式。截至 2025 年 8 月，仍在 MV2 上的扩展已在 Chrome 138/139 中被禁用。如今再在 MV2 上做新的构建已经没有意义。
一款浏览器扩展能否同时在 Chrome、Firefox 和 Edge 上工作？
可以。WebExtensions API 为三者提供了一个共同的接口面。存在命名空间差异(browser.* vs chrome.*)、Service Worker 支持差异、侧边栏可用性不一致，但兼容层能处理大部分问题。一份代码库、三次分开的商店提交(Chrome Web Store、Firefox Add-ons、Microsoft Edge Add-ons)。
开发并发布一款 Chrome 扩展需要多久？
取决于复杂度。一款单一用途的简单扩展需要 2 到 4 周开发，加上几天的 Web Store 审核。中等复杂度、带鉴权和 API 集成的扩展需要 4 到 8 周。带后端和变现的完整 AI 扩展需要 8 到 14 周。首次 Web Store 审核最多可能需要一周，具体取决于您请求的权限。
浏览器扩展中可以加入哪些 AI 功能？
页面总结、写作辅助、研究上下文浮现、带页面感知的侧边栏聊天。所有这些都需要一个后端代理来处理 LLM API 调用，因为您不能安全地在扩展包中暴露 API 密钥。Chrome 127+ 还通过内置的 Prompt API 支持端侧推理，适用于离线和隐私敏感的应用场景，无需后端往返。
