docs: 更新文档内容并优化语言风格
重构所有文档内容，使用更简洁直接的语言风格 更新架构、插件开发、部署等核心文档 优化代码示例和图表说明 统一术语和格式规范
This commit is contained in:
@@ -1,8 +1,8 @@
|
||||
# 核心概念：事件流转
|
||||
|
||||
在 NEO Bot Framework 中，所有交互都由**事件**驱动。理解一个事件从被接收到最终被处理的完整流程，是掌握框架工作原理的关键。
|
||||
别管那些花里胡哨的，NEO Bot 的核心就是**事件驱动**。搞懂一个事件从哪来、到哪去，你就懂了一大半。
|
||||
|
||||
本节将以一个用户发送 `/echo hello` 的群聊消息为例，详细拆解其在框架内部的流转路径。
|
||||
下面就拿 `/echo hello` 这条傻瓜命令开刀，看看它在 Bot 内部是怎么裸奔的。
|
||||
|
||||
## 事件流转图
|
||||
|
||||
@@ -15,40 +15,40 @@ graph TD
|
||||
classDef plugin fill:#fce4ec,stroke:#c2185b,stroke-width:2px;
|
||||
|
||||
subgraph External [外部环境]
|
||||
OneBot[OneBot v11 实现端<br/>(如 NapCatQQ)]:::external
|
||||
OneBot["OneBot v11 实现端<br/>(如 NapCatQQ)"]:::external
|
||||
end
|
||||
|
||||
subgraph NeoBot [NEO Bot Framework]
|
||||
direction TB
|
||||
|
||||
subgraph Network [网络接入层]
|
||||
WS[WebSocket 连接<br/>core/ws.py]:::network
|
||||
WS["WebSocket 连接<br/>core/ws.py"]:::network
|
||||
end
|
||||
|
||||
subgraph Processing [核心处理层]
|
||||
Factory[事件工厂<br/>models/events/factory.py]:::core
|
||||
Dispatcher[命令管理器<br/>core/managers/command_manager.py]:::core
|
||||
Handler[事件处理器<br/>core/handlers/event_handler.py]:::core
|
||||
BotAPI[Bot API 封装<br/>core/bot.py]:::core
|
||||
Factory["事件工厂<br/>models/events/factory.py"]:::core
|
||||
Dispatcher["命令管理器<br/>core/managers/command_manager.py"]:::core
|
||||
Handler["事件处理器<br/>core/handlers/event_handler.py"]:::core
|
||||
BotAPI["Bot API 封装<br/>core/bot.py"]:::core
|
||||
end
|
||||
|
||||
subgraph Plugins [业务插件层]
|
||||
UserPlugin[用户插件<br/>plugins/*.py]:::plugin
|
||||
UserPlugin["用户插件<br/>plugins/*.py"]:::plugin
|
||||
end
|
||||
end
|
||||
|
||||
%% 事件上报流程 (实线)
|
||||
OneBot -- 1. WebSocket 消息 --> WS
|
||||
WS -- 2. 原始 JSON --> Factory
|
||||
Factory -- 3. Event 对象 --> WS
|
||||
WS -- 4. 分发事件 --> Dispatcher
|
||||
Dispatcher -- 5. 匹配指令/事件 --> Handler
|
||||
Handler -- 6. 调用处理函数 --> UserPlugin
|
||||
OneBot -- "1. WebSocket 消息" --> WS
|
||||
WS -- "2. 原始 JSON" --> Factory
|
||||
Factory -- "3. Event 对象" --> WS
|
||||
WS -- "4. 分发事件" --> Dispatcher
|
||||
Dispatcher -- "5. 匹配指令/事件" --> Handler
|
||||
Handler -- "6. 调用处理函数" --> UserPlugin
|
||||
|
||||
%% API 调用流程 (虚线)
|
||||
UserPlugin -. 7. 调用 bot.send() .-> BotAPI
|
||||
BotAPI -. 8. 封装 API 请求 .-> WS
|
||||
WS -. 9. 发送 JSON .-> OneBot
|
||||
UserPlugin -. "7. 调用 bot.send()" .-> BotAPI
|
||||
BotAPI -. "8. 封装 API 请求" .-> WS
|
||||
WS -. "9. 发送 JSON" .-> OneBot
|
||||
|
||||
%% 链接样式
|
||||
linkStyle 0,1,2,3,4,5 stroke:#333,stroke-width:2px;
|
||||
@@ -59,43 +59,43 @@ graph TD
|
||||
|
||||
### 1. 接收 WebSocket 消息 (`core/ws.py`)
|
||||
|
||||
* 当用户在 QQ 群里发送消息时，OneBot v11 实现端（如 NapCatQQ）会将其打包成一个 JSON 格式的数据，并通过 WebSocket 连接发送给框架。
|
||||
* `core/ws.py` 中的 `_listen_loop` 方法持续监听连接，接收到这个原始的 JSON 字符串。
|
||||
* *注*: 这里使用了 `orjson` 进行极速反序列化。
|
||||
* 你在群里发了条消息，OneBot (比如 NapCatQQ) 就会把它打包成一个 JSON，通过 WebSocket 扔给 Bot。
|
||||
* `core/ws.py` 里的 `_listen_loop` 一直在那蹲着，收到这个 JSON 字符串。
|
||||
* *注*: 这里用了 `orjson`，反序列化速度飞快。
|
||||
|
||||
### 2. 事件对象实例化 (`models/events/factory.py`)
|
||||
### 2. 变成对象 (`models/events/factory.py`)
|
||||
|
||||
* `ws.py` 将接收到的 JSON 数据传递给 `EventFactory.create_event()`。
|
||||
* `EventFactory` 会根据 JSON 中的 `post_type` 字段（例如 `"message"`）和 `message_type` 字段（例如 `"group"`），智能地将其解析并实例化为对应的 Python 对象，例如 `GroupMessageEvent`。
|
||||
* 这个 `Event` 对象包含了所有事件信息，并且具有清晰的类型提示，方便后续处理。
|
||||
* `ws.py` 拿到 JSON 后，扔给 `EventFactory.create_event()`。
|
||||
* 工厂类眼疾手快，看一眼 `post_type` 是 `"message"`，`message_type` 是 `"group"`，直接把它变成一个 `GroupMessageEvent` 对象。
|
||||
* 这时候它就不是一堆冷冰冰的 JSON 了，而是个活生生的 Python 对象，有属性有方法，写代码的时候 IDE 还能给你补全。
|
||||
|
||||
### 3. 事件初步处理与分发 (`core/ws.py`)
|
||||
### 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)`。
|
||||
* `ws.py` 拿到这个对象后，干两件事：
|
||||
1. **塞 Bot 实例**：把 `self.bot` 塞进 `event.bot` 里。这样你在插件里拿到事件，就能直接 `event.reply()` 回复，不用到处找 Bot 实例。
|
||||
2. **扔出去**：把事件扔给 `matcher.handle_event(bot, event)`，也就是命令管理器。
|
||||
|
||||
### 4. 指令匹配与处理器查找 (`core/managers/command_manager.py`)
|
||||
### 4. 找找谁来处理 (`core/managers/command_manager.py`)
|
||||
|
||||
* `CommandManager` (即 `matcher`) 是事件处理的核心中枢。
|
||||
* 它的 `handle_event` 方法会首先判断事件类型。对于消息事件，它会将其交给内部的 `MessageHandler`。
|
||||
* `MessageHandler` 会检查消息内容是否以已注册的命令前缀（如 `/`）开头。
|
||||
* 如果匹配成功（例如 `/echo`），它会从已注册的命令字典中查找对应的处理函数（即在 `echo.py` 中被 `@matcher.command("echo")` 装饰的函数）。
|
||||
* `CommandManager` (就是代码里的 `matcher`) 是个大管家。
|
||||
* 它看了一眼：“哟，是条消息”，然后转手交给 `MessageHandler`。
|
||||
* `MessageHandler` 拿着放大镜看消息内容：“是以 `/` 开头的吗？”
|
||||
* 如果是 `/echo`，它就去翻小本本（注册的命令列表），找到了 `plugins/echo.py` 里那个被 `@matcher.command("echo")` 标记的函数。
|
||||
|
||||
### 5. 执行插件逻辑 (`plugins/echo.py`)
|
||||
### 5. 干活 (`plugins/echo.py`)
|
||||
|
||||
* `MessageHandler` 找到了匹配的处理器后，会调用它，并将 `Event` 对象和解析出的参数（`args`）传递进去。
|
||||
* 此时，控制权就完全交给了插件开发者编写的函数，例如 `handle_echo_command(event, args)`。
|
||||
* 插件函数可以执行任意逻辑，比如操作数据库、请求外部 API，或者调用 `Bot` 的 API 来回复消息。
|
||||
* 找到了正主，直接调用它，把 `Event` 对象和参数 `args` 传进去。
|
||||
* 这时候就是你写的代码在跑了。你想干啥都行，查数据库、调 API、或者直接复读。
|
||||
|
||||
### 6. API 调用与响应 (`core/bot.py` -> `core/ws.py`)
|
||||
### 6. 回复消息 (`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 实现端。
|
||||
* 你在插件里写了 `await event.reply("hello")`。
|
||||
* 这行代码背后，是 `core/bot.py` 把你的话封装成了一个标准的 OneBot API 请求（`send_group_msg`）。
|
||||
* 然后 `core/ws.py` 再次出场，把这个请求变成 JSON，通过 WebSocket 扔回给 OneBot。
|
||||
|
||||
### 7. 消息发送
|
||||
### 7. 发送成功
|
||||
|
||||
* OneBot v11 实现端接收到 API 请求后，执行相应的操作——将 "hello" 这条消息发送到原来的 QQ 群。
|
||||
* OneBot 收到请求，把 "hello" 发到了群里。
|
||||
* 完事。
|
||||
|
||||
至此，一个完整的事件流转闭环就完成了。理解这个流程后，您就能明白框架是如何将底层的网络通信与高层的插件逻辑解耦，并为开发者提供便捷接口的。
|
||||
|
||||
Reference in New Issue
Block a user