Chrome扩展如何无需后端在同设备多Chrome Profile间触发动作传数据

Chrome不同Profile的扩展运行在完全隔离的沙箱环境中，官方消息传递API仅支持同Profile内通信，无原生跨Profile通信能力，以下是3种无需后端服务的可行实现方案：

方案1：同谷歌账号下使用chrome.storage.sync（最简单，推荐优先尝试） #

前提条件 #

所有Profile登录同一个谷歌账号，扩展manifest中申请storage权限。

实现逻辑 #

利用谷歌账号的扩展存储同步能力，所有Profile监听sync存储区的变化事件，触发动作时写入带唯一标识的事件数据，其他Profile收到变更后判断执行对应逻辑。

示例代码 #

// manifest.json 权限配置
{
  "manifest_version": 3,
  "permissions": ["storage"],
  "background": {
    "service_worker": "background.js"
  }
}

// 触发端（页面按钮点击逻辑）
document.querySelector('#sayHello').addEventListener('click', async () => {
  // 生成全局唯一事件ID，避免重复执行
  const eventId = crypto.randomUUID();
  // 生成当前Profile唯一标识，避免触发自身执行
  const profileId = (await chrome.storage.local.get('profileId')).profileId;
  // 写入sync存储区触发同步
  await chrome.storage.sync.set({
    crossProfileEvent: {
      id: eventId,
      type: 'sayHello',
      payload: 'sayHello',
      senderId: profileId
    }
  });
  // 1秒后清理事件，避免占用sync存储配额
  setTimeout(() => chrome.storage.sync.remove('crossProfileEvent'), 1000);
});

// background.js 所有Profile通用监听逻辑
const processedEventIds = new Set();
// 初始化当前Profile唯一标识，安装时生成
chrome.runtime.onInstalled.addListener(async () => {
  const res = await chrome.storage.local.get('profileId');
  if (!res.profileId) {
    await chrome.storage.local.set({profileId: crypto.randomUUID()});
  }
});
// 监听存储区变化
chrome.storage.onChanged.addListener(async (changes, area) => {
  if (area !== 'sync' || !changes.crossProfileEvent) return;
  const event = changes.crossProfileEvent.newValue;
  if (!event || processedEventIds.has(event.id)) return;
  const currentProfileId = (await chrome.storage.local.get('profileId')).profileId;
  // 跳过自身触发的事件
  if (event.senderId === currentProfileId) return;

  // 执行对应动作
  if (event.type === 'sayHello') {
    console.log(event.payload);
  }
  // 标记事件已处理，5秒后清理缓存避免内存溢出
  processedEventIds.add(event.id);
  setTimeout(() => processedEventIds.delete(event.id), 5000);
});

优缺点 #

• 优点：实现成本极低，无需额外权限，逻辑稳定
• 缺点：依赖谷歌账号登录，同步延迟在100ms~3s之间，不适合传输超过8KB的大数据

方案2：系统剪贴板轮询（无账号依赖） #

前提条件 #

扩展manifest中申请clipboardRead、clipboardWrite权限，Manifest V3需要搭配offscreen文档处理剪贴板读写。

实现逻辑 #

• 触发端先备份用户当前剪贴板内容，将带固定前缀标识的事件数据写入剪贴板，100ms后恢复原有剪贴板内容，避免影响用户正常使用
• 所有Profile的后台每100ms轮询一次剪贴板内容，匹配到扩展专属前缀后解析事件数据，判断未处理过则执行对应动作

优缺点 #

• 优点：不依赖谷歌账号，延迟低，实现简单
• 缺点：轮询会消耗少量CPU资源，不适合传输超过1MB的大数据，短时间内高频触发可能丢事件

方案3：File System Access API读写本地共享文件（无账号依赖，适合大数据） #

前提条件 #

扩展申请file://*权限，首次使用时引导所有Profile的用户选择同一个本地目录作为共享存储目录。

实现逻辑 #

• 所有Profile的扩展定时轮询共享目录的文件变更
• 触发端将事件数据写入共享目录下的临时文件，文件名带唯一事件ID和时间戳
• 其他Profile检测到新的事件文件后，读取内容执行对应动作，执行完成后删除临时文件

优缺点 #

• 优点：不依赖任何账号，支持传输任意大小的数据，稳定性高
• 缺点：首次使用需要用户手动授权选择共享目录，开发成本稍高

内容的提问来源于stack exchange，提问作者Muhammad Usman