Chrome扩展Manifest V3如何在不同内容脚本间共享通用函数

同一Chrome扩展注入到同一页面的所有内容脚本，默认共享同一个专属隔离JS全局作用域。这个作用域和网页原生JS环境完全隔离，不会和页面变量产生冲突，是实现跨脚本函数复用的核心基础。

针对你现有两个独立内容脚本重复定义相同通用函数的场景，可通过以下方式实现无重复维护的函数共享：

方案1：抽离独立共享脚本，按注入顺序复用 #

这是维护成本最低、改动最小的方案，操作逻辑非常直接：

• 将两个脚本中重复的通用函数抽离到独立的sharedUtils.js文件中，两个业务脚本里不再保留重复的函数定义：

// sharedUtils.js 抽离后的通用逻辑
function generalFunction(number) {
    return number * number;
}

• 在manifest配置中，按照「共享脚本在前，业务脚本在后」的顺序列出脚本路径。Chrome会严格按照数组配置的顺序依次执行脚本，等共享脚本加载完成、全局注册好通用函数后，后续的业务脚本就能直接调用，不需要重复定义：
  • 如果两个业务脚本匹配相同的站点规则，可以放到同一个content_scripts配置块下：

  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["sharedUtils.js", "contentScript1.js", "contentScript2.js"]
    }
  ]
  

  • 如果两个业务脚本匹配不同的站点规则，不需要强行合并配置，只需要在每个匹配规则对应的js数组里，把共享脚本列在业务脚本前面即可：

  "content_scripts": [
    {
      "matches": ["https://a.com/*"],
      "js": ["sharedUtils.js", "contentScript1.js"]
    },
    {
      "matches": ["https://b.com/*"],
      "js": ["sharedUtils.js", "contentScript2.js"]
    }
  ]
  

• 改造完成后的两个业务脚本，只保留各自的业务逻辑，直接调用共享的通用函数即可：

// contentScript1.js
function myCode() {
    return 1 + 1;
}
// 直接调用共享脚本里的通用函数
console.log(generalFunction(3));

// contentScript2.js
function differentCode() {
    return "man walking on the moon";
}
// 无需重复定义函数，直接调用
console.log(generalFunction(4));

注意：脚本的执行顺序和配置顺序完全一致，必须保证共享脚本先于业务脚本加载，否则会触发generalFunction is not defined的报错。

方案2：命名空间封装，避免全局命名冲突 #

如果担心通用函数直接暴露在全局作用域，可能和同隔离世界下的其他脚本变量重名，可以在共享脚本里把通用函数挂载到一个专属的全局对象上，从根源避免命名污染：

// sharedUtils.js 带命名空间的共享逻辑
window.ExtensionShared = {
  generalFunction: function(number) {
    return number * number;
  }
};

两个业务脚本里调用时，通过专属命名空间对象访问即可，不会和其他全局变量产生冲突：

// 业务脚本中的调用方式
console.log(ExtensionShared.generalFunction(5));

方案3：动态注入场景的复用逻辑 #

如果你的业务脚本不是通过manifest静态配置的，而是由service worker通过chrome.scripting.executeScript动态注入的，只需要保持「先注入共享脚本，再注入业务脚本」的顺序，同样可以正常复用函数，示例代码：

// service worker中的动态注入逻辑
await chrome.scripting.executeScript({
  target: { tabId: targetTabId },
  // 数组顺序就是脚本执行的顺序
  files: ["sharedUtils.js", "contentScript2.js"]
});

不推荐的实现路径 #

不要为了复用通用函数，把工具函数放到service worker里，再通过消息传递实现调用：

• 通用工具函数一般是同步执行逻辑，走跨上下文消息通信会把原本一步完成的同步调用改成异步，需要改造所有调用点的代码逻辑，大幅增加维护成本。
• 高频的通用函数调用会产生大量跨上下文通信的开销，拖慢执行效率。只有涉及扩展权限、本地存储读写等内容脚本无法直接访问的逻辑，才适合放到service worker里处理。

特殊场景提示：如果两个内容脚本被手动配置为注入到不同的JS世界（比如一个在默认的ISOLATED隔离世界，一个在网页原生的MAIN世界），两个上下文的全局作用域是完全隔离的，无法直接通过上述方式共享函数，这种情况需要通过DOM自定义事件做跨世界通信桥接，属于少数特殊配置场景。

内容的提问来源于stack exchange，提问作者Yam Shargil