对浏览器扩展，什么是MV3？升级MV3有哪些影响？

以下是AI总结的有关MV3的说明。

对Quicker的浏览器扩展来说，最重要的变化是：

• 无法再支持“运行后台脚本”功能。
• 对标签页运行自定义脚本，需要开启浏览器的开发者模式。

谷歌官网说明：https://developer.chrome.com/docs/extensions/develop/migrate/what-is-mv3 

最新的MV2支持期限说明：https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline 

-------

什么是 MV3 (Manifest V3)？

MV3，全称为 Manifest Version 3，是 Google Chrome 浏览器扩展平台的最新规范版本，Google 将其描述为"浏览器扩展安全、性能和隐私的下一次演进"。你可以把它理解为一套新的规则和 API（应用程序编程接口），用于定义扩展程序如何构建、它们拥有哪些权限以及它们如何与浏览器交互。

推出 MV3 的主要目标（根据 Google 的说法）是为了提升扩展程序的安全性、隐私性和性能。它旨在让扩展程序更易于审查，减少滥用潜力，并提高浏览器的整体效率。

基于谷歌的计划，将于2025年6月彻底淘汰基于MV2的浏览器扩展，并在此之前默认禁用这些扩展。

升级到 MV3 的主要影响：

MV3 引入了多项重大变更，对扩展程序的开发和功能产生了深远影响：

1. 后台脚本 (Background Scripts) 替换为 Service Workers:

   • MV2: 使用持久的后台页面或事件页面，这些页面可以在扩展程序的生命周期内或在需要时长时间运行。
   • MV3: 使用 Service Workers。Service Workers 是事件驱动的，意味着它们只在需要响应特定事件（如用户点击按钮、收到消息等）时运行，并在空闲时自动终止。
   • 影响: 这要求开发者改变处理后台任务、管理状态和监听事件的方式。需要长时间运行的任务或依赖持久状态的逻辑需要重新设计。这有助于降低扩展程序的内存占用，但也增加了开发的复杂性。

2. 网络请求拦截方式改变 (webRequest API vs declarativeNetRequest API):

   • MV2: webRequest API 允许扩展程序在运行时动态地、完全地拦截、检查和修改网络请求。这为广告拦截器和隐私工具提供了强大的能力。
   • MV3: 限制了阻塞版本的 webRequest API，并主推 declarativeNetRequest API。后者要求开发者预先声明一组规则（规则集），浏览器根据这些规则来处理网络请求（阻止、重定向等），而不是让扩展程序在请求发生时执行任意代码来决定如何处理。
   • 影响: 这是最具争议的变化之一。虽然 declarativeNetRequest 在某些情况下性能更好且更隐私（因为它不读取请求内容），但它限制了广告拦截器和其他网络修改工具的灵活性和能力，因为它们无法像以前那样基于复杂的动态逻辑来过滤请求。

3. 禁止执行远程托管代码 (No Remote Hosted Code):（这一条变更导致无法运行自定义的后台脚本）

   • MV2: 允许扩展程序引用并执行来自远程服务器的 JavaScript 文件。
   • MV3: 严格禁止。所有扩展程序执行的代码都必须包含在扩展程序的包内。扩展程序不能再从其自己的服务器或其他地方下载并执行代码。
   • 影响: 这是为了提高安全性，防止扩展程序开发者在用户不知情的情况下偷偷更新恶意代码。但这也限制了一些需要动态加载逻辑或功能的扩展。

4. 内容安全策略 (Content Security Policy - CSP) 的变化:

   • MV3 对扩展程序可以使用的 CSP 进行了更严格的限制，特别是关于可以执行的脚本来源。

5. API 现代化:

   • 许多旧的回调式 (Callback-based) API 被现代的基于 Promise 的 API 所取代，这使得异步代码更易于编写和管理。

对需要执行自定义代码的扩展的特别影响：

这一点直接关系到你问题中的核心关切。MV3 对“执行自定义代码”施加了严格的限制，具体取决于“自定义代码”的含义：

1. 执行远程服务器上的代码:

   • 绝对禁止: 如上所述，MV3 不允许扩展程序加载并执行来自其服务器或其他远程来源的 JavaScript 文件。如果你的扩展依赖于从服务器动态获取并执行脚本来实现核心功能或更新逻辑，那么这种模式在 MV3 下将不再可行。
   • 原因: 安全性。这是为了防止恶意扩展在通过审核后，通过远程加载的代码引入恶意行为。
   • 解决方案:
     • 将所有必要的代码逻辑打包到扩展程序内部。
     • 可以通过从服务器获取配置数据（例如 JSON 文件），然后根据这些数据在本地已有的代码中调整行为，但这不能是执行新的代码。
     • 对于确实需要动态逻辑的情况，可能需要寻找完全不同的实现方式，或者接受功能上的限制。

2. 执行用户提供的代码 (例如 User Scripts):

   • 严格限制: MV3 对 eval() 等能够执行字符串形式代码的函数以及动态创建 <script> 标签的能力施加了更严格的限制（尤其是在扩展程序的后台 Service Worker 和内容脚本中）。虽然内容脚本仍然可以在网页上下文中注入和执行脚本，但其能力和方式受到了更严格的 CSP 约束。
   • userScripts API: 为了支持像 Tampermonkey/Greasemonkey 这样的用户脚本管理器，Chrome 引入了一个新的 userScripts API (仍在发展中)，允许以更受控、更安全的方式注册和执行用户脚本。但这与之前在 MV2 中直接注入和执行任意脚本的方式不同。
   • 影响: 依赖于在扩展程序自身上下文中（非网页上下文）动态生成和执行代码的功能会受到很大影响。用户脚本管理器需要适配新的 API 和限制。

3. 执行扩展包内但动态生成的代码:

   • 同样受到 eval() 和相关函数限制的影响。如果扩展需要在运行时基于某些逻辑动态构建并执行代码字符串，这在 MV3 中会变得非常困难或不可能，尤其是在 Service Worker 中。

总结：

升级到 MV3 对所有扩展程序都是一个重大的变化，但对于那些依赖执行远程代码或在扩展程序上下文中动态执行任意字符串代码的扩展来说，影响尤其巨大。

• 核心变化: 从持久后台页到事件驱动的 Service Workers，从强大的 webRequest 到声明式的 declarativeNetRequest，以及严格禁止执行远程托管代码。
• 对自定义代码执行的影响:
  • 无法再从服务器加载并执行代码。所有代码必须打包在扩展内。
  • 在扩展程序自身环境中动态执行代码（如使用 eval）受到严格限制。
• 开发者需要:
  • 进行大量的代码重构以适应 Service Workers 和新的 API。
  • 寻找替代方案来实现之前依赖远程代码或动态代码执行的功能，可能需要接受某些功能的削减或改变实现逻辑（例如，用数据配置代替远程代码）。
  • 适应 declarativeNetRequest 的规则集限制，这可能影响内容过滤类扩展的能力。

总而言之，MV3 以提升安全和隐私为名，对扩展程序的能力进行了诸多限制，特别是代码执行方面。这迫使开发者重新思考扩展的设计和实现方式，对于依赖旧有灵活性的扩展来说，迁移可能是一个充满挑战的过程。