K2CrO4/NeoBot
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

docs: 更新文档内容并优化语言风格

Browse Source 
重构所有文档内容，使用更简洁直接的语言风格
更新架构、插件开发、部署等核心文档
优化代码示例和图表说明
统一术语和格式规范
This commit is contained in:
K2cr2O1
2026-01-13 04:09:13 +08:00
parent a6704a55ff
commit 7880f0f928
7 changed files with 361 additions and 421 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
docs/core-concepts/architecture.md
View File

@@ -1,62 +1,62 @@
# 核心架构
NEO Bot Framework 不是那种随便写写的玩具。它的架构设计只有一个核心目标：**极致性能与稳定性的平衡**。
别把 NEO Bot 当成那些写着玩的玩具。这玩意的设计目标就一个：**又快又稳**。
我们不搞花里胡哨的抽象，只做最有效的工程实践。
不搞虚头巴脑的，只上最实在的。
## 1. 运行时架构
### Python 3.14 + JIT
我们激进地采用了 Python 3.14，并默认开启 JIT (Just-In-Time) 编译器。
* **原理**: JIT 会在运行时分析热点代码，将其编译为机器码，跳过字节码解释过程。
* **收益**: CPU 密集型任务（如复杂的正则匹配、数据处理）性能提升显著。
我们直接上了 Python 3.14，默认就开 JIT (即时编译)。
* **啥原理**: JIT 会在代码跑的时候，把那些一遍遍执行的热点代码直接编译成机器码，下次再跑就不用解释器了，快得飞起。
* **有啥用**: 正则匹配、数据处理这种吃 CPU 的活儿，效果特别明显。
### Mypyc 编译 (AOT)
光有 JIT 还不够。核心模块（`core/ws.py`, `core/managers/*.py`）支持通过 Mypyc 编译为 C 扩展。
* **原理**: Mypyc 利用 Python 的类型提示，将 Python 代码直接翻译成 C 代码，并编译为二进制 `.pyd` 或 `.so` 文件。
* **收益**: 核心路径的执行速度接近 C 语言，完全摆脱 GIL 的部分束缚。
光 JIT 还不够爽。核心模块（`core/ws.py`, `core/managers/*.py`）我们都用 Mypyc 编译成了 C 扩展。
* **啥原理**: Mypyc 直接把带类型提示的 Python 代码翻译成 C，再编译成二进制文件。
* **有啥用**: 核心代码跑起来跟 C 差不多快，还能绕开 GIL。
### 异步 IO 模型
* **Linux**: 强制使用 `uvloop`，这是目前最快的 Python 异步事件循环，基于 libuv（Node.js 同款）。
* **Windows**: 使用原生 `ProactorEventLoop` (IOCP)，虽然不如 uvloop，但在 Windows 上是最优解。
* *注*: 我们禁用了 `winloop`，因为它与 Playwright 存在兼容性问题。
* **Linux**: 必须用 `uvloop`，这玩意儿是基于 libuv（Node.js 同款）的，公认最快。
* **Windows**: 用的是系统自带的 IOCP，虽然没 uvloop 猛，但在 Windows 上已经是最好的选择了。
* *注*: 我们把 `winloop` 禁了，因为它跟 Playwright 八字不合。
## 2. 网络架构
### 正向 WebSocket + FastAPI 混合模式
这是一个独特的混合架构，兼顾了部署便利性和功能扩展性。
这套组合拳，既方便部署，又能随便扩展。
* **连接层 (Client)**: Bot 主动通过 WebSocket 连接到 OneBot (NapCat)。
* **优势**: 不需要公网 IP，不需要内网穿透，只要能上网就能跑。
* **服务层 (Server)**: Bot 内部启动一个 FastAPI 服务。
* **优势**: 提供 HTTP API、Webhook 接收、静态资源托管（如帮助图片、Web 控制台）。
* **连接层 (Client)**: Bot 是个客户端，主动去连 OneBot (NapCat)。
* **好处**: 你电脑能上网就行，不用搞公网 IP，不用内网穿透。
* **服务层 (Server)**: Bot 自己也带了个 FastAPI 服务。
* **好处**: 能对外提供 HTTP 接口，还能搞个 Web 控制台啥的。
```mermaid
graph LR
subgraph Local [本地环境 / 服务器]
subgraph Local [你的电脑/服务器]
Bot[NEO Bot]
FastAPI[FastAPI Server]
Browser[Playwright Pool]
end
subgraph Remote [OneBot / 外部]
subgraph Remote [外部]
NapCat[NapCatQQ]
User[用户浏览器]
User["用户浏览器"]
end
Bot -- WebSocket (Client) --> NapCat
User -- HTTP --> FastAPI
Bot -- 控制 --> Browser
Bot -- "WebSocket (主动连接)" --> NapCat
User -- "HTTP (访问网页)" --> FastAPI
Bot -- "内部调用" --> Browser
```
## 3. 资源管理架构
### 单例管理器 (Singleton Managers)
所有的核心组件（指令、权限、浏览器、图片）都是全局单例。
* **零开销访问**: 任何插件都可以直接 import 使用，无需传递上下文。
* **状态一致性**: 全局共享状态，拒绝数据同步问题。
所有管事的（指令、权限、浏览器、图片）都是全局独一份。
* **随便用**: 在哪都能直接 `import`，不用传来传去。
* **数据统一**: 全局就一份数据，不会乱。
### 资源池化 (Pooling)
我们拒绝“用完即扔”的浪费行为。
* **Browser Pool**: 浏览器页面预先创建，用完归还，拒绝反复启动进程。
* **Connection Pool**: Redis 和 HTTP 请求共享连接池，拒绝反复握手。
我们这没有“一次性”的说法，用完的东西都得回收。
* **Browser Pool**: 浏览器页面提前开好，用完洗干净放回去，谁也别想每次都等浏览器启动。
* **Connection Pool**: Redis 和 HTTP 请求都用连接池，省掉反复建连接的开销。

88
docs/core-concepts/event-flow.md
View File

@@ -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" 发到了群里。
* 完事。
至此，一个完整的事件流转闭环就完成了。理解这个流程后，您就能明白框架是如何将底层的网络通信与高层的插件逻辑解耦，并为开发者提供便捷接口的。

119
docs/core-concepts/singleton-managers.md
View File

@@ -1,92 +1,80 @@
# 核心概念：单例管理器
在 `core/managers/` 目录下，存放着一系列全局唯一的**管理器（Managers）**。它们是 NEO Bot Framework 功能的核心实现，负责处理事件、管理权限、加载插件等关键任务。
`core/managers/` 这地方，放的都是些**管事的（Managers）**。它们是 NEO Bot 的权力核心。
理解这些管理器的职责，有助于您更好地利用框架提供的能力，并进行更高级的开发。
## 为啥非得是单例 (Singleton)？
## 设计模式：单例 (Singleton)
说白了，就是**全局独一份，省事**。
框架中所有的管理器都采用了**单例设计模式**。这意味着在整个应用程序的生命周期中，每个管理器类只会存在一个实例。
* **到处都能用**: 在插件里 `import` 就行，不用传来传去。
* **数据不打架**: 权限、命令这些东西，全局就一份，改了都认。
* **省资源**: Redis 连接池、浏览器这种东西，开一个就够了，多了浪费。
**为什么使用单例？**
我们专门在 `core/utils/singleton.py` 搞了个基类，继承一下就行。
* **全局访问点**: 任何模块（尤其是插件）都可以方便地导入并使用同一个管理器实例，无需手动传递。
* **状态共享**: 管理器内部维护的状态（如已注册的命令、用户权限列表）是全局共享和一致的。
* **资源统一管理**: 对于像 Redis 连接这样的资源，单例模式确保了全局只有一个连接池，避免了资源的浪费和冲突。
## 认识一下这帮“官”
框架在 `core/utils/singleton.py` 中提供了一个 `Singleton` 基类，所有管理器都继承自它，以轻松实现单例模式。
### 1. `CommandManager` (外号 `matcher`)
## 核心管理器介绍
* **怎么找**: `from core.managers.command_manager import matcher`
* **管啥**:
* **总调度**: 所有消息都得从它这过一遍，它说了算分给谁。
* **发牌的**: 你用的 `@matcher.command()` 这种装饰器，就是它发的。
* **对号入座**: 消息来了，它负责对一下，看是哪个插件的活儿。
### 1. `CommandManager` (全局实例: `matcher`)
写插件天天都得跟它打交道。
* **文件**: `core/managers/command_manager.py`
* **全局实例**: `from core.managers.command_manager import matcher`
* **核心职责**:
* **事件处理中枢**: 它是事件流转的核心，负责接收所有类型的事件，并将其分发给相应的底层处理器。
* **装饰器提供者**: 为插件提供了 `@matcher.command()`, `@matcher.on_notice()` 等一系列装饰器，用于注册事件处理器。
* **指令匹配**: 内部维护了一个指令注册表，能够根据消息内容匹配到对应的处理函数。
### 2. `PermissionManager` (外号 `permission_manager`)
`matcher` 是插件开发者最常打交道的管理器。
* **怎么找**: `from core.managers.permission_manager import permission_manager`
* **管啥**:
* **划分三六九等**: `ADMIN`, `OP`, `USER` 这些等级都是它定的。
* **记小本本**: 谁有啥权限，都记在 `core/data/permissions.json` 里。
* **会自动变通**: 查权限的时候，它会把 `AdminManager` 里的超管也当成 `ADMIN`。
### 2. `PermissionManager` (全局实例: `permission_manager`)
### 3. `AdminManager` (外号 `admin_manager`)
* **文件**: `core/managers/permission_manager.py`
* **全局实例**: `from core.managers.permission_manager import permission_manager`
* **核心职责**:
* **权限定义与检查**: 定义了 `ADMIN`, `OP`, `USER` 等权限等级，并提供了 `check_permission` 方法来验证用户权限。
* **数据持久化**: 负责从 `core/data/permissions.json` 文件中加载和保存用户权限设置。
* **与 `AdminManager` 联动**: 在检查权限和获取所有用户权限时，会自动合并机器人管理员（来自 `AdminManager`）的数据，将其识别为最高权限 `ADMIN`。
### 3. `AdminManager` (全局实例: `admin_manager`)
* **文件**: `core/managers/admin_manager.py`
* **全局实例**: `from core.managers.admin_manager import admin_manager`
* **核心职责**:
* **管理员管理**: 提供 `add_admin`, `remove_admin`, `is_admin` 等接口，用于管理机器人的超级管理员列表。
* **数据同步**: 实现了内存、`core/data/admin.json` 文件以及 Redis 缓存之间的数据同步，确保管理员列表的一致性和高效查询。
* **怎么找**: `from core.managers.admin_manager import admin_manager`
* **管啥**:
* **钦差大臣**: 专门管机器人的超级管理员，增删改查都在这。
* **三级缓存**: 内存 -> Redis -> 文件，又快又稳。
### 4. `PluginManager`
* **文件**: `core/managers/plugin_manager.py`
* **核心职责**:
* **插件加载**: 负责扫描 `plugins/` 目录，导入所有合法的插件模块。
* **元数据提取**: 读取插件文件中定义的 `__plugin_meta__` 字典，用于 `/help` 指令等功能。
* **热重载支持**: `load_all_plugins` 函数被 `main.py` 中的文件监控服务调用，以实现插件的热重载。
* **管啥**:
* **拉人头**: 启动时把 `plugins/` 目录下的插件都拉进来。
* **热更新**: 你改了插件代码，它负责重载，不用重启机器人。
此管理器通常在后台工作，开发者较少直接与其交互。
这家伙一般在幕后，你基本不用找它。
### 5. `RedisManager` (全局实例: `redis_manager`)
### 5. `RedisManager` (外号 `redis_manager`)
* **文件**: `core/managers/redis_manager.py`
* **全局实例**: `from core.managers.redis_manager import redis_manager`
* **核心职责**:
* **连接管理**: 负责初始化和管理与 Redis 服务器的异步连接。
* **提供实例**: 通过 `redis_manager.redis` 属性，为其他模块提供一个可用的 `redis` 客户端实例。
* **怎么找**: `from core.managers.redis_manager import redis_manager`
* **管啥**:
* **接线员**: 管着和 Redis 的连接。
* **提供工具**: 你要用 Redis，就找它要 `redis_manager.redis`。
### 6. `BrowserManager` (全局实例: `browser_manager`)
### 6. `BrowserManager` (外号 `browser_manager`)
* **文件**: `core/managers/browser_manager.py`
* **全局实例**: `from core.managers.browser_manager import browser_manager`
* **核心职责**:
* **浏览器生命周期管理**: 负责 Playwright 浏览器的启动和关闭。
* **页面池 (Page Pool)**: 维护一个预热的浏览器页面池（默认 3 个）。
* **资源复用**: 提供 `get_page()` 和 `release_page()` 接口，让渲染任务直接复用现有页面，避免了每次创建新页面的巨大开销。
* **怎么找**: `from core.managers.browser_manager import browser_manager`
* **管啥**:
* **浏览器司机**: 负责启动和关闭 Playwright。
* **开个页面池**: 提前准备好几个空白页面（默认3个），你要用直接拿，省下几百毫秒的启动时间。
* **循环利用**: 用完记得还回来 (`release_page`)，建设节约型社会。
### 7. `ImageManager` (全局实例: `image_manager`)
### 7. `ImageManager` (外号 `image_manager`)
* **文件**: `core/managers/image_manager.py`
* **全局实例**: `from core.managers.image_manager import image_manager`
* **核心职责**:
* **图片渲染**: 基于 Jinja2 模板和 Playwright 浏览器生成图片。
* **模板缓存**: 自动缓存编译后的 Jinja2 模板，避免重复 IO 和解析。
* **资源调度**: 自动从 `BrowserManager` 借用和归还页面，开发者无需关心底层浏览器操作。
* **怎么找**: `from core.managers.image_manager import image_manager`
* **管啥**:
* **美工**: 把数据塞进网页模板，然后用浏览器咔嚓一下截图。
* **记性好**: 模板用一次就记住，下次直接用缓存。
* **自动借还**: 它会自动找 `BrowserManager` 借页面，你只管喊一声 `render_template` 就行。
## 如何在插件中使用管理器
## 咋用？
在您的插件中，只需通过 `import` 语句导入相应管理器的全局实例即可使用。
简单粗暴：`import` 就完事了。
**示例**: 在插件中检查用户是否为管理员。
**举个栗子**: 查查这人是不是管理员。
```python
# plugins/my_plugin.py
@@ -97,11 +85,10 @@ from models.events.message import MessageEvent
@matcher.command("secret")
async def secret_command(event: MessageEvent):
# 使用 permission_manager 检查用户权限
# 只有管理员能看
is_admin = await permission_manager.check_permission(event.user_id, ADMIN)
if is_admin:
await event.reply("这是一个只有管理员能看到的秘密。")
await event.reply("这是秘密！")
else:
await event.reply("抱歉，您没有权限执行此命令。")
await event.reply("你没权限看这个。")
```