Electron 加载 Manifest V3 扩展时出现事件报错，如何排查？

2026-11-04数据小许

结论

你提供的代码已经使用了 current_session.extensions.loadExtension(extensionPath)。接下来建议先定位 background.js 中读取 onRemoved 的表达式，确认它前面的对象为什么是 undefined。

Electron 只支持部分 Chrome Extensions API，不能保证任意 Chrome 扩展都能直接运行。扩展使用 Manifest V3，也不代表它依赖的全部 API 都受支持。支持范围可参考 Electron 扩展文档。对于 41.0.3，仍需结合该版本的实现和实际运行结果确认。

当前日志不足以确定出错的是 chrome.tabs、chrome.windows、chrome.action，还是扩展内部的其他对象，也不足以给出保证可用的配置修改。

先找到事件所属的对象

错误信息是：

Cannot read properties of undefined (reading 'onRemoved')

这表示代码正在从一个值为 undefined 的对象上读取 onRemoved。例如，假设实际代码为：

chrome.windows.onRemoved.addListener(handleRemoved);

那么这条错误对应的是 chrome.windows 为 undefined。这个例子只用于解释错误含义，不能据此认定原扩展使用了 chrome.windows。

建议按以下顺序检查：

打开扩展目录中的 manifest.json，确认 background.service_worker 指向的入口。
在入口及其依赖文件中搜索 onRemoved 和 onClicked。
如果代码被压缩成一行，先格式化，再根据调用栈定位具体表达式。
在扩展的 Service worker 上下文中检查该表达式的父对象，不要在 Electron 主进程或普通页面中检查。

例如，只有源码确实引用了下列命名空间时，才针对它们添加诊断输出：

console.log('chrome.tabs:', typeof chrome.tabs);
console.log('chrome.windows:', typeof chrome.windows);
console.log('chrome.action:', typeof chrome.action);

确认完整 API 名称后，再检查 Electron 的支持范围、manifest 声明和代码执行上下文。不要只凭事件名称判断缺少哪个权限。

优先处理后台脚本异常

日志先记录了 background.js 的未捕获异常，随后出现：

Service worker registration failed. Status code: 15

根据这个顺序，可以优先排查后台脚本是否在启动阶段抛出异常，导致 Service worker 注册失败。仅凭状态码不能断定唯一原因。

先修复最早出现的异常，重新加载扩展并查看完整日志。如果仍然注册失败，再检查 worker 入口路径、导入文件以及其他初始化错误。

如果某个事件只用于可选功能，可以在注册前检测能力。例如，只有实际依赖的是 chrome.action.onClicked 时，才使用类似判断：

if (chrome.action?.onClicked) {
  chrome.action.onClicked.addListener(handleActionClick);
} else {
  console.warn('chrome.action.onClicked is unavailable');
}

这里的 handleActionClick 代表扩展原有的处理函数。能力检测可以避免这处属性访问异常，但被跳过的功能不会执行。如果它属于核心功能，就需要适配或重新实现，不能把跳过注册视为修复完成。

检查加载时机与 Session

Electron 要求在 app 就绪后加载扩展，路径应指向包含 manifest.json 的解包目录，并使用持久化 Session。你使用的 persist:electron:line:extension 已符合持久化分区的命名要求。扩展还需要在每次应用启动时重新加载。参见 Extensions.loadExtension 文档。

可以先移除每次加载前的存储清理，保留一个便于排查的加载入口：

const { app, ipcMain, session } = require('electron');
const path = require('node:path');

const partition = 'persist:electron:line:extension';

ipcMain.handle('load-plugin', async () => {
  await app.whenReady();

  const currentSession = session.fromPartition(partition);
  const extensionPath = path.join(
    __dirname,
    'extensions/ophjlpahpchlmihnnnihgmmeilfjmjjc/3.6.0_0'
  );

  try {
    const extension = await currentSession.extensions.loadExtension(
      extensionPath
    );

    return { id: extension.id, name: extension.name };
  } catch (error) {
    console.error('Failed to load extension:', error);
    throw error;
  }
});

这个示例整理了加载流程，不会补齐扩展缺失的 API。加载调用成功后，仍需检查后台脚本是否正常执行。

需要使用扩展的窗口也应使用同一 Session。可以在现有窗口配置中设置相同的 webPreferences.partition，或者直接传入加载扩展时使用的 Session。如果分区不一致，需要单独修正；但分区不一致本身不能解释后台脚本中的所有属性访问异常。

clearStorageData() 也不能修复缺失的 API。原代码每次加载都清理该 Session 的存储，可能影响其中保存的登录状态或应用数据，排查时应避免不必要的清理。

追踪弃用提示的实际来源

日志提示旧的 session.loadExtension 被调用，但展示的代码已经使用新入口。需要继续搜索项目及相关依赖中的 .loadExtension(，检查是否还有其他加载路径、旧构建产物或第三方工具在调用旧 API。

这条弃用提示和 background.js 中的运行时异常应分别定位。更换加载入口不会自动解决扩展内部的 API 兼容问题。

如果确认扩展依赖当前环境缺失的核心能力，就需要修改扩展或在 Electron 应用中实现对应功能；如果无法修改扩展，则应选择支持其所需能力的运行环境。要进一步确定修改位置，还需要 manifest.json、涉及两个事件的源码及完整的 onClicked 报错。