如何在Manifest V3浏览器扩展中可靠设置徽章文本

原方案失效的核心原因 #

MV2的后台脚本是持久运行的，只要扩展启用，脚本就会一直处于活跃状态。你在脚本顶层直接调用chrome.action.setBadgeText()，会在扩展加载时执行一次，后续数值变化时的更新也能持续生效；浏览器重启后，脚本会自动重新执行顶层代码，徽章会被重新设置。

但MV3改用服务工作者（Service Worker）替代后台脚本，它的运行模式是事件驱动、非持久化的：

• 服务工作者只会在触发特定事件（如chrome.runtime.onInstalled、chrome.runtime.onStartup、书签变化事件等）时被唤醒执行，完成逻辑后会被浏览器自动休眠甚至销毁。
• 浏览器重启后，服务工作者不会自动执行顶层代码，只有当第一个触发它的事件到来时才会启动。如果没有事件触发，服务工作者处于未激活状态，你写在顶层的徽章设置代码自然不会执行，导致徽章丢失。

你猜测的解决方案原理 #

把chrome.action.setBadgeText()添加到onStartup和onInstalled事件监听器里，本质是利用这两个事件的触发时机，确保服务工作者被唤醒并重新设置徽章：

• chrome.runtime.onInstalled：在扩展安装、更新，或浏览器更新导致扩展重新加载时触发，此时服务工作者会被唤醒，执行徽章初始化逻辑。
• chrome.runtime.onStartup：浏览器启动时触发，这是浏览器重启后第一个能可靠唤醒服务工作者的事件之一，在这里重新计算书签数量并设置徽章，就能保证重启后徽章立刻显示。

另外，书签数量变化的场景也需要处理：要监听chrome.bookmarks.onChanged、chrome.bookmarks.onCreated、chrome.bookmarks.onRemoved等书签事件，在这些事件触发时重新计算数量并更新徽章——因为服务工作者处理完事件后可能休眠，但下一次事件触发时会再次被唤醒执行更新逻辑。

关键代码示例 #

// 封装计算特定文件夹书签数量的函数
async function getBookmarkFolderCount(folderId) {
  const bookmarks = await chrome.bookmarks.getChildren(folderId);
  return bookmarks.length.toString();
}

// 设置徽章文本的通用函数
async function updateBadge() {
  const count = await getBookmarkFolderCount("你的目标文件夹ID");
  await chrome.action.setBadgeText({ text: count });
  // 可选：设置徽章背景色
  await chrome.action.setBadgeBackgroundColor({ color: "#FF0000" });
}

// 扩展安装/更新时初始化徽章
chrome.runtime.onInstalled.addListener(async () => {
  await updateBadge();
});

// 浏览器启动时重新设置徽章
chrome.runtime.onStartup.addListener(async () => {
  await updateBadge();
});

// 书签变化时实时更新徽章
chrome.bookmarks.onChanged.addListener(async () => {
  await updateBadge();
});
chrome.bookmarks.onCreated.addListener(async () => {
  await updateBadge();
});
chrome.bookmarks.onRemoved.addListener(async () => {
  await updateBadge();
});

跨浏览器兼容注意事项 #

• Chrome和Firefox对MV3服务工作者的实现基本一致，核心逻辑通用；Firefox在服务工作者休眠策略上可能更宽松，但无需额外调整代码。
• 确保在manifest.json中声明必要权限："bookmarks"，并将background字段设置为"service_worker"而非原MV2的"scripts"。

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