控制反转（IoC）在异步组件库中旨在解决跨平台逻辑动态切换时的硬绑定问题，通过剥离创建、实现选择与初始化时机，统一收口平台适配，依赖接口而非具体实现，支持配置驱动装配、异步就绪保障及零业务代码变更的适配器替换。
控制反转（IoC）在异步组件库中不是为了“用上框架”，而是为了解决跨平台逻辑动态切换时的硬绑定问题。核心在于把“谁来创建、用哪个实现、何时初始化”这三件事从组件内部剥离，让平台适配逻辑收口在统一装配点，而非散落在每个 await new WeChatAdapter() 或 if (platform === 'qq') {...} 里。
明确抽象边界：定义平台无关接口契约
先不写任何具体实现，只聚焦语义——比如消息收发、会话管理、用户身份识别等能力，全部声明为 TypeScript interface 或 Python Protocol：
-
消息通道接口：包含
send(message: Message): Promise<void></void>、onMessage(handler: (msg: Message) => void)，不暴露 HTTP 请求细节或 WebSocket 生命周期 -
上下文抽象：如
PlatformContext提供getUserId()、getGroupId()，屏蔽微信 OpenID、QQ uin、Discord user_id 的差异 - 所有插件、中间件、业务处理器只依赖这些接口，绝不 import 具体平台类
集中装配：启动时按环境注入对应实现
避免在运行时做 switch platform 判断，而是在应用初始化阶段一次性完成映射：
- 配置驱动：读取
platform: 'wechat'后，调用createAdapter('wechat', config)返回统一接口实例 - 工厂封装：每个平台适配器的构造函数接收标准参数（如 token、timeout、重试策略），不依赖全局变量或单例状态
- 异步就绪保障：若某平台需异步初始化（如获取 access_token），工厂函数返回
Promise<adapter></adapter>，主流程 await 完成后再启动事件循环
跨层传递必须走接口，禁止跳层引用具体类型
常见错误是 UI 组件直接调用 adapter.sendMessage()，或插件内部 new 一个 QqMessageParser。正确方式是：
- Controller / EventHandler 只持有
MessageService接口，由上层注入 - 业务插件通过依赖参数接收
PlatformContext和MessageService，不感知底层如何连接微信服务器 - 当需要更换适配器（例如灰度切到新版 Discord adapter），只需改装配代码，零业务代码变更
利用异步生命周期解耦初始化与使用
NoneBot2 类框架的全异步设计天然支持 IoC 的延迟绑定：
- Adapter 实例可带
async init(): Promise<void></void>方法，在事件循环启动前统一调用 - 业务插件注册时不立即执行逻辑，而是注册 handler 函数，待消息到达时才触发——此时所有依赖已就绪
- 降级场景下，可注入一个
FallbackAdapter，它不真正发消息，只记录日志并 resolve，不影响主流程执行
