refactor(core): 重构核心模块结构并添加开发文档
将核心模块按功能重新组织为更清晰的结构,包括 managers、handlers 和 utils 目录 添加完整的开发文档,涵盖快速开始、项目结构、核心概念和插件开发指南 更新所有相关模块的导入路径以匹配新的结构 将单例模式实现提取到单独的 singleton.py 文件
This commit is contained in:
64
docs/core-concepts/event-flow.md
Normal file
64
docs/core-concepts/event-flow.md
Normal file
@@ -0,0 +1,64 @@
|
||||
# 核心概念:事件流转
|
||||
|
||||
在 NEO Bot Framework 中,所有交互都由**事件**驱动。理解一个事件从被接收到最终被处理的完整流程,是掌握框架工作原理的关键。
|
||||
|
||||
本节将以一个用户发送 `/echo hello` 的群聊消息为例,详细拆解其在框架内部的流转路径。
|
||||
|
||||
## 事件流转图
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[OneBot v11 实现端] -- WebSocket Message --> B(core/ws.py);
|
||||
B -- Raw JSON Data --> C(models/events/factory.py);
|
||||
C -- Event Object --> D(core/ws.py on_event);
|
||||
D -- Event Object --> E(core/managers/command_manager.py);
|
||||
E -- Event & Command Match --> F(core/handlers/event_handler.py);
|
||||
F -- Matched Handler --> G(plugins/echo.py);
|
||||
G -- Call API --> H(core/bot.py);
|
||||
H -- Send Request --> B;
|
||||
B -- WebSocket Send --> A;
|
||||
```
|
||||
|
||||
## 详细步骤
|
||||
|
||||
### 1. 接收 WebSocket 消息 (`core/ws.py`)
|
||||
|
||||
* 当用户在 QQ 群里发送消息时,OneBot v11 实现端(如 NapCatQQ)会将其打包成一个 JSON 格式的数据,并通过 WebSocket 连接发送给框架。
|
||||
* `core/ws.py` 中的 `_listen_loop` 方法持续监听连接,接收到这个原始的 JSON 字符串。
|
||||
|
||||
### 2. 事件对象实例化 (`models/events/factory.py`)
|
||||
|
||||
* `ws.py` 将接收到的 JSON 数据传递给 `EventFactory.create_event()`。
|
||||
* `EventFactory` 会根据 JSON 中的 `post_type` 字段(例如 `"message"`)和 `message_type` 字段(例如 `"group"`),智能地将其解析并实例化为对应的 Python 对象,例如 `GroupMessageEvent`。
|
||||
* 这个 `Event` 对象包含了所有事件信息,并且具有清晰的类型提示,方便后续处理。
|
||||
|
||||
### 3. 事件初步处理与分发 (`core/ws.py`)
|
||||
|
||||
* `ws.py` 的 `on_event` 方法接收到 `Event` 对象后,会做两件重要的事:
|
||||
1. **注入 `Bot` 实例**:将 `self.bot` 赋值给 `event.bot`。这使得插件开发者可以在事件处理器中直接通过 `event.reply()` 或 `event.bot.send(...)` 来调用 API。
|
||||
2. **分发事件**:将 `Event` 对象传递给全局的命令管理器 `matcher.handle_event(bot, event)`。
|
||||
|
||||
### 4. 指令匹配与处理器查找 (`core/managers/command_manager.py`)
|
||||
|
||||
* `CommandManager` (即 `matcher`) 是事件处理的核心中枢。
|
||||
* 它的 `handle_event` 方法会首先判断事件类型。对于消息事件,它会将其交给内部的 `MessageHandler`。
|
||||
* `MessageHandler` 会检查消息内容是否以已注册的命令前缀(如 `/`)开头。
|
||||
* 如果匹配成功(例如 `/echo`),它会从已注册的命令字典中查找对应的处理函数(即在 `echo.py` 中被 `@matcher.command("echo")` 装饰的函数)。
|
||||
|
||||
### 5. 执行插件逻辑 (`plugins/echo.py`)
|
||||
|
||||
* `MessageHandler` 找到了匹配的处理器后,会调用它,并将 `Event` 对象和解析出的参数(`args`)传递进去。
|
||||
* 此时,控制权就完全交给了插件开发者编写的函数,例如 `handle_echo_command(event, args)`。
|
||||
* 插件函数可以执行任意逻辑,比如操作数据库、请求外部 API,或者调用 `Bot` 的 API 来回复消息。
|
||||
|
||||
### 6. API 调用与响应 (`core/bot.py` -> `core/ws.py`)
|
||||
|
||||
* 当插件调用 `event.reply("hello")` 时,实际上是调用了 `core/bot.py` 中封装的 `send` 方法。
|
||||
* `Bot` 类会将这个调用转换为一个标准的 OneBot v11 API 请求(例如 `{"action": "send_group_msg", "params": {...}}`)。
|
||||
* 这个请求最终通过 `core/ws.py` 的 `call_api` 方法,被序列化为 JSON 字符串,并通过 WebSocket 发送回 OneBot v11 实现端。
|
||||
|
||||
### 7. 消息发送
|
||||
|
||||
* OneBot v11 实现端接收到 API 请求后,执行相应的操作——将 "hello" 这条消息发送到原来的 QQ 群。
|
||||
|
||||
至此,一个完整的事件流转闭环就完成了。理解这个流程后,您就能明白框架是如何将底层的网络通信与高层的插件逻辑解耦,并为开发者提供便捷接口的。
|
||||
Reference in New Issue
Block a user