Chromium 扩展事件系统深度解析：从 C++ 业务回调到 JS 监听器，一次说清楚

关注

原创 2026-04-09 18:39:49 349 阅读 AI 写同款· GEO 优化 ›

Electron与Flutter跨平台开发深度对比：架构、性能与选型指南跨平台开发框架是构建多端应用的核心技术，其核心原理在于通过一套代码库实现在不同操作系统上的部署。从技术实现上，主要分为基于Web技术栈的“套壳”方案和自绘引擎的统一渲染方案。前者利用成熟的Web生态实现快速开发，后者则通过高性能图形引擎保障一致的UI体验与流畅性能。在工程实践中，框架选型直接影响应用的资源消耗、启动速度、内存占用及长期维护成本。对于需要复杂Web内容集成、深度系统调用或已有Web技术栈的团队，基于Chromium的方案能提供更低的开发门槛和丰富的生态支持；而对于追求高性能渲染、统一多端体验且阅读详情

Chromium 扩展事件系统深度解析：从 C++ 业务回调到 JS 监听器，一次说清楚

这篇文章以一个非常具体、非常典型的案例为主线：浏览器内核侧某个业务服务在登录成功后触发 OnLoginSucceeded()，最终让扩展侧通过 chrome.account.onStatusChanged.addListener(...) 之类的方式收到事件通知。
文章重点不是停留在“某个函数调用了另一个函数”，而是把 事件源注册、扩展监听器注册、EventRouter 注册表维护、懒监听器处理、Profile 初始化时机、Browser 进程与 Renderer 进程的事件桥接 这几条线完整串起来。

一、为什么要写这篇文章

在 Chromium 扩展体系里，很多人一开始接触事件分发时，会把几个概念混在一起：

浏览器业务服务的 Observer 注册：比如同步服务、UI 服务、下载服务、阅读模式服务等把某个对象加入自己的观察者列表。
扩展 JS 侧的 addListener 注册：扩展在 JS 里调用某个 API 的 addListener()，表示自己愿意接收该事件。
EventRouter 的监听器注册表：浏览器进程里真正负责维护“哪个扩展正在监听哪个事件”的核心对象。
事件的最终分发：浏览器进程把事件通过 Mojo/IPC 发给扩展所在的 Renderer 或 Service Worker。

很多排查问题时，表面上像是在问“为什么事件没收到”，本质上可能是以下任意一环出问题：

业务事件源根本没有注册成功；
API schema 定义了事件，但扩展压根没把监听器加上；
扩展加了监听器，但 EventRouter 里没有记录；
EventRouter::DispatchEventToExtension() 发的是定向事件，但目标扩展 ID 不对；
扩展是懒加载后台页，事件发出时上下文并未唤起；
Profile 初始化顺序不对，事件源先发事件，而扩展系统还没 ready。

所以这篇文章的目标很明确：用一个真实案例，把这整个机制讲透。

二、本文的案例主线：`OnLoginSucceeded()`

给出的案例，本质上是下面这条链：

浏览器 Profile 初始化；
扩展系统初始化；
某个 browser-side 的 event router 对象被创建，例如 ExtensionAccountEventRouter；
它在 Init() 里向多个业务服务注册自己为 observer；
当登录服务通知“登录成功”时，observer 回调 OnLoginSucceeded()；
在这个回调里构造参数，然后调用 DispatchEvent(...)；
DispatchEvent(...) 再进入 EventRouter；
EventRouter 找到所有监听该事件的扩展监听器；
通过 Mojo/IPC 发送给扩展 Renderer / 扩展 Service Worker；
扩展 JS 中的 addListener(callback) 最终被调用。

看上去只是“一个回调转发事件”，但实际上中间至少跨了：

业务服务层
浏览器扩展桥接层
扩展事件路由层
Renderer 绑定层
扩展 JS API 层

这也是为什么这个案例特别适合拿来讲透 Chromium 扩展事件系统。

三、先区分两套完全不同的“注册”

理解这个系统的第一步，是把“注册”拆成两种完全不同的事情。

3.1 第一种注册：业务服务侧的 Observer 注册

这类注册发生在 browser 进程的 C++ 里。典型形式如下：

void ExtensionAccountEventRouter::Init() {
  if (profile_) {
    SyncService* sync_service = g_browser_process->sync_service();
    if (sync_service) {
      sync_service->GetSyncLogin()->AddObserver(this);
    }

    ExtensionUIService* extension_ui_service =
        g_browser_process->extension_ui_service();
    if (extension_ui_service) {
      extension_ui_service->AddObserver(this);
    }

    DownloadFileService* download_file_service =
        g_browser_process->download_file_service();
    if (download_file_service) {
      download_file_service->AddObserver(this);
    }
  }
}

这里的含义是：

ExtensionAccountEventRouter 这个对象本身并不是事件真正的源头；
它只是把自己注册到各个业务服务；
一旦业务服务内部状态变化，就会反向回调它。

换句话说，这里注册的是：
“谁来接收浏览器业务层产生的内部通知”。

它注册到的是各个 service 自己维护的 ObserverList。

3.2 第二种注册：扩展侧的 Listener 注册

另一种注册发生在扩展 JS 里，例如：

chrome.channel.onBuiltinPageMessage.addListener(function(data) {
  console.log(data);
});

或者在本文案例里，更抽象地写成：

chrome.account.onStatusChanged.addListener(function(isLoggedIn) {
  console.log('login state changed', isLoggedIn);
});

这里的含义是：

扩展向浏览器声明：“我对这个事件感兴趣”；
浏览器必须把这个监听关系记下来；
将来只要同名事件发生，就要把它发给这个扩展。

这类注册最终会进入 EventRouter 内部，存放在 EventListenerMap 中。

它注册的是：
“哪个扩展在监听哪个扩展事件”。

3.3 两种注册的本质区别

可以直接对比：

维度	业务侧注册	扩展侧注册
注册者	browser 进程里的 C++ 对象	扩展 JS / 扩展上下文
注册目标	各业务 Service 的 ObserverList	`EventRouter` 的监听器表
解决的问题	谁来接收浏览器内部状态变化	哪些扩展要收到某个 API 事件
数据结构	各服务内部的 observer list	`EventListenerMap`
方向	Service → EventRouter bridge	Browser → Extension

很多时候看到一个 Init()->AddObserver(this)，那是在建立 事件源到桥接器 的路径；
而看到 addListener()，那是在建立 桥接器到扩展端 的路径。

两者合在一起，完整链路才成立。

四、从系统启动讲起：这个 bridge 对象什么时候创建

如果要真正看透 OnLoginSucceeded() 为什么能走到扩展侧，不能只看单个 event router 类，还要看它是什么时候被构造、什么时候 Init() 的。

给出的调用链非常关键，核心是：

ProfileManager::DoFinalInitForServices()
ExtensionSystem::InitForRegularProfile()
ExtensionSystemImpl::Shared::Init()
ExtensionService::Init()
构造并初始化 ExtensionAccountEventRouter

我们按层展开。

4.1 Profile 级别入口：`ProfileManager::DoFinalInitForServices()`

这是 Profile 生命周期中一个很关键的阶段。逻辑核心是：

void ProfileManager::DoFinalInitForServices(Profile* profile,
                                            bool go_off_the_record) {
#if BUILDFLAG(ENABLE_EXTENSIONS_CORE)
  bool extensions_enabled = !go_off_the_record;
  extensions::ExtensionSystem::Get(profile)->InitForRegularProfile(
      extensions_enabled);
#endif
}

这说明：

扩展系统不是在浏览器进程一起来就无条件初始化；
它是挂在某个 Profile 上的；
只有 Profile 走到最终服务初始化阶段，扩展系统才真正开始启动。

这一步很重要，因为后面所有事件路由都依赖 Profile：

EventRouter::Get(browser_context) 是按 BrowserContext/Profile 取实例；
扩展启用状态、权限、incognito 可见性，都是 Profile 维度；
浏览器内部服务也经常是 Profile 隔离的。

所以从架构上讲，扩展事件系统本来就是 Profile scoped 的。

4.2 扩展系统入口：`InitForRegularProfile()`

贴出的逻辑：

void ExtensionSystemImpl::InitForRegularProfile(bool extensions_enabled) {
  if (user_script_manager() || extension_service()) {
    return;
  }

  shared_->Init(extensions_enabled);
}

这里做了两件事：

防止重复初始化；
把真正的初始化逻辑委托给 shared_->Init(...)。

这意味着很多后面看到的对象，比如：

ExtensionService
ServiceWorkerManager
UserScriptManager
QuotaService
以及各种 extension-side 基础设施

都是在这个阶段准备起来的。

4.3 扩展系统核心构建：`ExtensionSystemImpl::Shared::Init()`

贴出的这一段最关键的地方是：

extension_service_ = std::make_unique<ExtensionService>(...);
...
extension_service_->Init();

也就是说：

扩展系统内部大量对象先构造；
然后由 ExtensionService::Init() 进入真正的扩展服务初始化；
而我们的业务 bridge event router，正是在这个阶段被创建和初始化的。

这一步在事件系统里有一个很深的含义：
只有扩展系统 ready 之后，业务事件桥接器才应该开始注册并对外发扩展事件。

否则会出现两个典型问题：

扩展监听关系还没建立，事件已经发了；
EventRouter 还没就绪，事件无法路由。

4.4 真正挂上业务 bridge：`ExtensionService::Init()`

贴出的关键逻辑类似：

abp_event_router_.reset(new extensions::ExtensionAbpEventRouter(profile_));
abp_event_router_->Init();

account_event_router_.reset(
    new extensions::ExtensionAccountEventRouter(profile_));
account_event_router_->Init();

这里其实就是在做一件事：

给每一种业务域，创建一个专属的 ExtensionXXXEventRouter；
这些对象统一承担“把业务层事件翻译成扩展 API 事件”的职责。

这类对象一般都不是扩展系统最底层基础设施，而是 业务扩展桥接层。

可以把它们理解为：

上游连着浏览器业务服务；
下游连着扩展事件系统；
中间做事件名映射、参数打包、权限/上下文约束。

五、案例核心：`OnLoginSucceeded()` 到底做了什么

现在进入本文主角。

典型逻辑如下：

void ExtensionAccountEventRouter::OnLoginSucceeded(
    const sync::Account& account) {
  base::Value::List args;
  args.Append(base::Value(true));
  DispatchEvent(profile_, kOnAccountStatusChanged, std::move(args));
}

这段代码看似简单，但它完成了“浏览器业务语义”向“扩展事件语义”的一次翻译。

它做了三件关键事情：

5.1 从业务回调切入

OnLoginSucceeded(...) 不是自己主动执行的，而是由上游服务回调触发。
这说明它的角色不是事件源，而是 事件桥接者。

5.2 把业务状态编码成扩展事件参数

base::Value::List args;
args.Append(base::Value(true));

这一步是 参数协议转换。

上游回调签名可能是：

OnLoginSucceeded(const sync::Account& account)

而扩展事件要求的参数协议可能是：

只告诉登录状态；
或者告诉账号信息、token 状态、来源类型；
或者封成 dict/object。

所以这里并不是机械转发，而是把上游业务数据转换为扩展事件 schema 所要求的参数格式。

5.3 把事件送入扩展事件总线

DispatchEvent(profile_, kOnAccountStatusChanged, std::move(args));

这一步的本质是：
从业务域切入扩展域。

从这里开始，后续链路不再是某个业务 service 自己的 observer 体系，而进入 Chromium 扩展系统统一的事件派发机制。

六、扩展事件系统的核心：`EventRouter`

如果只用一句话概括 EventRouter：

它是 browser 进程中扩展事件系统的中心路由器，负责接收事件、记录监听关系、筛选目标、唤醒懒上下文，并最终把事件发给正确的扩展上下文。

这里要重点看它的两个职责：

维护监听器注册表；
执行事件分发。

6.1 核心数据结构：`EventListenerMap`

前面总结过，这部分非常关键，而且要保留。
EventRouter 内部通过 listeners() 暴露其监听器注册表：

EventListenerMap& listeners() { return listeners_; }

而 EventListenerMap 的核心就是按事件名组织监听器：

std::map<std::string, ListenerList> listeners_;

这意味着：

key：事件名，例如 channel.onBuiltinPageMessage；
value：一个监听器列表；
同一个事件可能同时被多个扩展、多个进程、多个上下文监听。

所以它不是 “event_name -> one listener”，而是：
event_name -> 多个 EventListener。

6.2 `EventListener` 里到底保存了什么

每个 EventListener 本质上就是一个“事件接收端描述对象”。

典型字段包括：

event_name_：监听的是哪个事件；
extension_id_：属于哪个扩展；
listener_url_：如果不是扩展而是 URL listener，则记录 URL；
process_：监听器所在的 RenderProcessHost；
browser_context_：属于哪个 BrowserContext/Profile；
is_for_service_worker_：是否是扩展 service worker；
service_worker_version_id_：对应 service worker 版本；
worker_thread_id_：worker thread id；
filter_：过滤器；
matcher_id_：如果设置了 filter，则绑定在 event filter 上的 matcher id。

这几个字段很关键，因为它们决定了后续分发时：

发给谁；
发到哪个进程；
发给主线程页面还是 service worker；
是否需要按 filter 精确匹配；
当前是不是 lazy listener。

七、扩展监听器是怎么注册进 `EventRouter` 的

这一段是整个问题最容易“只知其然，不知其所以然”的地方。

7.1 扩展 JS 侧的起点：`addListener()`

例如：

chrome.channel.onBuiltinPageMessage.addListener(callback);

或者：

chrome.account.onStatusChanged.addListener(callback);

这个 addListener() 在 JS 看上去只是一个同步调用，但实际上它会通过扩展绑定层一路进入 browser 进程。

7.2 Renderer 到 Browser：Mojo 接口

EventRouter 实现了 mojom::EventRouter 接口，这意味着 renderer 可以通过 Mojo 调 browser 侧的方法。

关键接口包括：

也就是说，扩展 JS 的监听注册，最终会落到这些 browser-side 方法。

7.3 主线程监听注册：`AddListenerForMainThread()`

EventRouter::AddListenerForMainThread() 的逻辑已经总结过，核心是：

void EventRouter::AddListenerForMainThread(
    mojom::EventListenerPtr event_listener) {
  auto* process = GetRenderProcessHostForCurrentReceiver();
  if (!process)
    return;

  const mojom::EventListenerOwner& listener_owner =
      *event_listener->listener_owner;
  if (listener_owner.is_extension_id()) {
    AddEventListener(event_listener->event_name, process,
                     listener_owner.get_extension_id());
  } else if (listener_owner.is_listener_url()) {
    AddEventListenerForURL(event_listener->event_name, process,
                           listener_owner.get_listener_url());
  }
}

这个函数的作用可以翻译成一句人话：

当前 renderer 进程告诉 browser：“我这个扩展（或者这个 URL 页面）想监听某个事件，请记下来。”

这里的 process 很关键，它来自 GetRenderProcessHostForCurrentReceiver()，说明监听器注册是与当前发起 Mojo 调用的 renderer 进程上下文绑定的。

7.4 最终写入注册表：`EventListenerMap::AddListener()`

真正把监听器放进注册表的是：

bool EventListenerMap::AddListener(std::unique_ptr<EventListener> listener) {
  if (HasListener(listener.get()))
    return false;
  if (listener->filter()) {
    ...
  }
  EventListener* listener_ptr = listener.get();
  listeners_[listener->event_name()].push_back(std::move(listener));
  delegate_->OnListenerAdded(listener_ptr);
  return true;
}

这段代码有几个细节必须讲清楚：

7.4.1 先判重

if (HasListener(listener.get()))
  return false;

说明同一个监听器不会被重复插入。

7.4.2 如果带 filter，要额外进入 filter 子系统

if (listener->filter()) {
  ...
}

也就是说，监听器注册不仅仅是 list append。
如果事件支持 filter，它还会额外挂进 EventFilter，以后派发时按条件匹配。

7.4.3 核心入表动作

listeners_[listener->event_name()].push_back(std::move(listener));

这就是前面总结的那句核心结论：
按 event_name 分组存入 map。

7.4.4 通知 observer

delegate_->OnListenerAdded(listener_ptr);

这里的 delegate 是 EventRouter 本身。
所以 EventRouter 不只是“持有 map”，它还会在监听器变更时拿到通知，去更新其它状态或者通知外部观察者。

八、`EventRouter` 如何维护监听器注册表的附加状态

单纯知道有个 map<string, vector<listener>> 还不够，还要理解 EventRouter 围绕这张表做了哪些维护。

8.1 监听器增删回调

在 EventRouter 附近，有 OnListenerRemoved() 这类实现。它会把监听器变化封装成 EventListenerInfo，再通知注册到 observer_map_ 上的观察者。

也就是说：

EventListenerMap 负责存储；
EventRouter 负责感知变化；
如果某些模块关心“某个事件现在有没有 listener”，它们可以通过 observer 机制得到通知。

8.2 Renderer 进程生命周期绑定

ObserveProcess()、RenderProcessExited()、RenderProcessHostDestroyed() 这几段很重要。

它们说明：

监听器不是永久不变的；
它们和 renderer 进程生命周期绑定；
一旦 renderer 进程退出或销毁，该进程对应的监听器会被清理。

这能避免一个严重问题：
renderer 崩了，但 browser 还以为它在监听事件，导致事件发送到无效目标。

8.3 Lazy listener 的持久化注册状态

在 GetRegisteredEvents() 等逻辑里，可以看到 ExtensionPrefs 被用来读取 lazy/service worker listener 的已注册事件列表。

这意味着：

对于非持久常驻的扩展背景上下文，浏览器需要知道“虽然当前没进程，但它理论上对哪些事件感兴趣”；
所以 lazy listener 并不等于“完全不存在”；
它会以另一种形式保留在系统里，用于后续唤醒。

九、`DispatchEventToExtension()` 到底做了什么

这是前面明确要求解释的接口，也是文章必须保留和展开的重点。

先给结论：

EventRouter::DispatchEventToExtension() 的作用，是把一个事件定向发给指定扩展，而不是广播给所有监听者。

它与 BroadcastEvent() 的差异非常大。

9.1 三种常见派发接口的定位差异

EventRouter 常用的几个派发接口：

BroadcastEvent()：广播到所有监听该事件的监听器；
DispatchEventToExtension()：发给指定扩展；
DispatchEventToURL()：发给指定 URL 监听页面；
DispatchEventWithLazyListener()：按 lazy listener 语义定向分发。

可以把它们理解为：

接口	目标集合	使用场景
`BroadcastEvent()`	所有 listener	全局广播事件
`DispatchEventToExtension()`	单个 extension id	定向通知某个扩展
`DispatchEventToURL()`	单个 URL	WebUI / 特定页接收
`DispatchEventWithLazyListener()`	单个扩展的 lazy context	新装扩展、特殊上下文唤起

9.2 定向分发的核心思路

虽然前面给的伪逻辑是抽象版，但本质描述是对的：

void EventRouter::DispatchEventToExtension(const ExtensionId& extension_id,
                                           std::unique_ptr<Event> event) {
  // 1. 从 listeners_ 中查找该扩展注册的监听器
  // 2. 遍历匹配 event_name 的监听器
  // 3. 对每个监听器：
  //    - 如果是 lazy listener：唤醒扩展后台页/Service Worker
  //    - 如果是普通 listener：直接向 process 发送事件
  // 4. 最终进入 DispatchExtensionMessage(...)
}

这段逻辑的本质不是“拿到 ext_id 就直接发”。
它必须先做 监听匹配，因为一个扩展即便存在，也不代表它监听了这个事件。

所以“扩展存在”与“扩展监听事件”是两回事。

9.3 最终真正跨进程派发的是 `DispatchExtensionMessage()`

在 event_router.cc 中，真正把事件送往 renderer 的核心函数是 DispatchExtensionMessage()：

void EventRouter::DispatchExtensionMessage(
    content::RenderProcessHost* rph,
    int worker_thread_id,
    content::BrowserContext* browser_context,
    const mojom::HostID& host_id,
    int event_id,
    const std::string& event_name,
    base::Value::List event_args,
    UserGestureState user_gesture,
    mojom::EventFilteringInfoPtr info,
    mojom::EventDispatcher::DispatchEventCallback callback)

这个函数做的事情非常核心：

为这次分发准备 DispatchEventParams；
填充 event_name、event_id、host_id、worker_thread_id 等；
调用 RouteDispatchEvent()；
最终通过 mojom::EventDispatcher 把事件发到 renderer / worker。

也就是说：

DispatchEventToExtension() 是“路由决策层”；
DispatchExtensionMessage() 是“派送执行层”。

这个分层非常清晰。

9.4 `RouteDispatchEvent()` 的意义

RouteDispatchEvent() 负责真正把消息送到目标 dispatcher：

dispatcher->DispatchEvent(std::move(params), std::move(event_args),
                          std::move(callback));

这里说明一件非常重要的事：
扩展事件从 browser 到 renderer 不是手写 IPC message，而是走了统一的 Mojo 接口 EventDispatcher。

所以从架构上看，事件传递是：

browser 侧：EventRouter
传输层：Mojo associated interface
renderer 侧：EventDispatcher
JS 侧：bindings + callback 调用

十、`BroadcastEvent()` 与 `DispatchEventToExtension()` 的本质区别

很多人看到这两个接口时，只觉得一个“广播”，一个“定向”，但实际差异比这更深入。

10.1 `BroadcastEvent()`

适合这种场景：

某类事件对所有监听该 API 的扩展都可见；
比如浏览器状态变化、某个全局通知、某个系统事件。

流程是：

根据 event_name 找到所有监听器；
对每个监听器检查上下文和权限；
对满足条件的监听器逐个发出。

10.2 `DispatchEventToExtension()`

适合这种场景：

事件天然只属于某个扩展；
或者某业务逻辑明确知道目标扩展 ID；
或者只想避免其它扩展收到同名事件。

流程是：

先确定目标 extension id；
再在该扩展已注册的 listener 中找同名事件；
最后只对该扩展做派发。

10.3 一个容易误判的问题

有些人会想：

我已经知道 extension_id 了，直接发不就行了，为什么还要查 listener？

答案是：

因为 Chromium 扩展事件系统是 listener-driven 的。
扩展是否收到事件，不只取决于它“是谁”，还取决于它“有没有注册监听该事件”。

否则就会破坏 WebExtension / Chrome Extension 事件模型的基本契约。

十一、懒监听器（Lazy Listener）为什么复杂

前面的总结里保留了 lazy listener，这部分必须展开，因为它正是 Chromium 扩展事件系统最有技术含量的点之一。

11.1 什么是 lazy listener

如果扩展后台页不是常驻，或者扩展基于 service worker，那么在某个时间点它可能没有活跃进程。但它依然通过 manifest 和历史注册关系表达了：

“如果某个事件来了，请把我唤醒并投递给我。”

此时该监听器在 browser 侧就会表现为：

process_ == nullptr
IsLazy() 返回 true

即前面总结的：

当扩展后台页未运行时，监听器以 “lazy” 形式存在。

11.2 lazy listener 为什么必要

如果没有 lazy listener，扩展事件模型会有严重缺陷：

浏览器为了让扩展能收到事件，必须永远常驻其后台页；
内存和进程成本会非常高；
service worker 模型也无法成立。

所以 Chromium 的做法是：

把监听关系存在 browser 侧；
扩展上下文不活跃时，不代表监听关系消失；
事件到达时，先唤起上下文，再投递事件。

11.3 lazy listener 的处理流程

前面已经总结出最核心的三步：

检测到 listener->IsLazy() 为 true；
通过 LazyEventDispatcher 或相关 lazy dispatch 工具唤醒扩展；
扩展启动并重新建立上下文后，事件被投递。

从设计上看，它其实是在解决一个经典问题：
如何把“事件到达”与“执行上下文当前不存在”解耦。

这是 Chromium 扩展事件机制比普通 observer/listener 模型更复杂的根本原因。

十二、事件源侧的完整初始化链路，再串一次

前面给出的“扩展事件系统完整初始化链路解析”必须保留，而且要讲得更系统。下面重新组织。

12.1 调用链总览

ProfileManager::DoFinalInitForServices()
    ↓
ExtensionSystem::Get(profile)->InitForRegularProfile(extensions_enabled)
    ↓
ExtensionSystemImpl::Shared::Init()
    ↓
extension_service_ = std::make_unique<ExtensionService>(...)
    ↓
ExtensionService::Init()
    ↓
account_event_router_.reset(new ExtensionAccountEventRouter(profile_))
account_event_router_->Init()
    ↓
sync_service->GetSyncLogin()->AddObserver(this)
extension_ui_service->AddObserver(this)
download_file_service->AddObserver(this)
    ↓（业务状态变化触发）
OnLoginSucceeded(const sync::Account& account)
    ↓
DispatchEvent(profile_, kOnAccountStatusChanged, args)
    ↓
EventRouter::DispatchEventToExtension(extension_id, event)
    ↓（经 Mojo IPC）
扩展 JS callback 执行

12.2 每一步的职责边界

层级	代表对象	职责
Profile 层	`ProfileManager`	决定初始化顺序和时机
扩展系统层	`ExtensionSystemImpl`	扩展基础设施启动
扩展服务层	`ExtensionService`	各业务 bridge event router 的创建
业务桥接层	`ExtensionAccountEventRouter`	业务 observer 注册 + 参数打包 + 分发入口
事件路由层	`EventRouter`	查找监听器、分发事件
Renderer 层	扩展 JS 上下文	接收事件、触发 JS callback

12.3 高频误区速览

误区 A：只要 C++ 里 DispatchEvent 了，扩展一定能收到。
实际：还取决于扩展是否注册监听器、是否有权限、是否在正确 profile、是否需要唤醒懒上下文。
误区 B：只看 browser 侧日志就够了。
实际：listener 注册可能根本没成功，必须同时看 JS 侧 addListener 是否执行、browser 侧 listener map 是否有记录。
误区 C：observer 注册成功就等于扩展事件注册成功。
实际：这是两套独立注册体系，前者连接业务源，后者连接扩展接收端。

十三、两个高频疑问的专门解答

13.1 疑问：addListener 来自"扩展进程"还是 renderer 进程？

先给结论：

扩展 JS 上下文运行在 renderer 进程（或 renderer 承载的 Service Worker 线程）。所谓"扩展进程"只是逻辑上的称呼，本质是承载扩展上下文的 renderer 进程实例。

为什么会混淆

从产品语义看，addListener() 是"扩展行为"，会让人自然联想到"扩展进程"；
但从 Chromium 多进程模型看，扩展 background page、popup、扩展页面都跑在 renderer 进程 里，只是这个 renderer 进程可能专门服务于扩展，不与普通网页共享。

注册链路

扩展 JS 执行 chrome.account.onStatusChanged.addListener(callback)
    ↓（在 renderer/扩展进程中）
绑定层将调用转换为 Mojo 调用
    ↓（跨进程 IPC）
browser 进程 EventRouter::AddListenerForMainThread()
    ↓
EventListenerMap::AddListener()
    ↓
listeners_["account.onStatusChanged"].push_back(listener)

一句话总结

语义上：扩展端注册；
实现上：扩展所处 renderer 上下文向 browser 发起注册；
“扩展进程” ≈ 承载扩展上下文的 renderer 进程，二者不对立。

13.2 疑问：`addListener(callback)` 底层是否依赖 V8？

结论：依赖，而且是第一层依赖。

分层分析

层级	技术组件	职责
JS/V8 绑定层（renderer）	V8 + 扩展绑定层	暴露 `addListener` 给 JS，接收并保存回调对象
IPC 层	Mojo	将注册请求从 renderer 发到 browser
browser 路由层	`EventRouter`	持久登记监听关系

renderer 绑定层中，事件对象通过如 EventEmitter::AddListener 将方法挂到 V8 对象上：

// extensions/renderer/bindings/event_emitter.cc
return Wrappable<EventEmitter>::GetObjectTemplateBuilder(isolate)
    .SetMethod("addListener", &EventEmitter::AddListener)
    ...

因此：

callback 作为 v8::Function 在 V8 上下文里被接收；
其生命周期与 V8 上下文绑定；
浏览器侧 EventListenerMap 登记的是监听关系（扩展 ID + 事件名），不是 V8 函数对象本身；
事件回发时，browser 将事件 payload 通过 Mojo 发回 renderer，renderer 在 V8 上下文里找到 callback 并调用。