插件与能力装配
lens 的每种采集能力都是一个插件：归因、身份、行为、错误、性能各自独立。理解「插件怎么装、能力怎么解耦、授权怎么驱动启停」，就能解释为什么命令式 API 会静默 no-op、为什么关掉某维授权后采集真的停了。
一切能力都是插件
| 装配方式 | 插件 | 受 Consent 管控 |
|---|---|---|
| 默认装（构造期固定加） | AttributionPlugin（归因） · IdentityPlugin（身份） | 否，基础能力始终采集 |
opt-in（构造参数 plugins 显式加） | TrackingPlugin（行为） · ErrorPlugin（错误） · PerformancePlugin（性能） | 是，对应一维 Consent |
ts
import { TripoLens, TrackingPlugin, ErrorPlugin, PerformancePlugin } from '@tripo3d/lens';
const trace = new TripoLens({
app: 'tripo',
configUrl: '...',
endpoint: '...',
// attribution / identity 已默认装，这里只追加 opt-in（追加而非替换）
plugins: [
new TrackingPlugin({ autoTrack: true }),
new ErrorPlugin({ captureApi: true }),
new PerformancePlugin(),
],
});插件只产出 RawEvent、经 ctx.emit 交给管线，不直接发请求（见 事件的一生）。插件的注册与生命周期（setup / teardown）由 L2 的 PluginRegistry 统一管理。
Capability 注册表：能力供需解耦
插件之间禁止互相 import。需要跨插件协作时，走 CapabilityRegistry：提供方注册具名能力，消费方按名取用，双方互不认识对方实例。
| 能力名 | 提供方 | 消费方 |
|---|---|---|
breadcrumb-provider | TrackingPlugin | L4 给 error 附面包屑 |
tracking-commands / error-commands / performance-commands | 对应 opt-in 插件 | TripoLens 门面按名委托 |
这正是命令式 API（track / captureException / startTransaction …）的工作机制：TripoLens 自身不持有插件实例，运行期按名 get 能力再委托。
为什么命令式 API 会「静默 no-op」
取不到能力时（未装对应插件，或授权撤销后插件已 teardown），get 返回 undefined，命令直接 no-op——不拦截、不报错。所以未装 TrackingPlugin 时调 trace.track(...) 是安全的。
Capability 与 EventBus 分工不同：EventBus 传瞬时控制信令（
user.identified/consent.changed），Capability 暴露可随时拉取的能力 / 数据源。
Consent 驱动差量启停
三个 opt-in 插件各受一维 Consent 管控（tracking / errors / performance）：
init()读回持久化的授权状态，按授权情况决定 setup 哪些 opt-in 插件。updateConsent/revokeConsent触发差量启停——只动发生变化的维度（新授权 → setup，撤销 → teardown），不全量重建。- 撤销维度后插件被 teardown，其命令式能力随之注销，对应 API 自动回落 no-op。
授权的命令式 API、默认值与撤销语义见 Consent 授权；归因 / 身份不受管控，始终采集。
相关
- 架构总览：插件位于 L3，PluginRegistry / CapabilityRegistry 位于 L2
- 事件的一生：插件产出的 RawEvent 之后如何加工上送
- Consent 授权：三维授权的命令式 API 与默认值