docs: 更新文档内容并优化语言风格
重构所有文档内容，使用更简洁直接的语言风格 更新架构、插件开发、部署等核心文档 优化代码示例和图表说明 统一术语和格式规范
This commit is contained in:
@@ -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 请求都用连接池，省掉反复建连接的开销。
|
||||
|
||||
@@ -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" 发到了群里。
|
||||
* 完事。
|
||||
|
||||
至此，一个完整的事件流转闭环就完成了。理解这个流程后，您就能明白框架是如何将底层的网络通信与高层的插件逻辑解耦，并为开发者提供便捷接口的。
|
||||
|
||||
@@ -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("你没权限看这个。")
|
||||
```
|
||||
|
||||
@@ -1,102 +1,98 @@
|
||||
# 部署指南
|
||||
|
||||
当您的机器人开发完成并准备投入生产环境时，本指南将为您提供部署的最佳实践和建议。
|
||||
把 Bot 扔到服务器上长期运行，比在自己电脑上跑要多几个步骤。
|
||||
|
||||
## 1. 生产环境配置
|
||||
## 1. 环境准备
|
||||
|
||||
与开发环境不同，生产环境要求更高的稳定性和安全性。
|
||||
### a. 安装 Python 3.14
|
||||
|
||||
### 创建生产配置文件
|
||||
别用太旧的版本，也别用最新的，就用 3.14。怎么装我就不废话了，自己想办法。
|
||||
|
||||
建议您复制一份 `config.toml` 并重命名为 `config.prod.toml`，专门用于生产环境。
|
||||
### b. 安装依赖
|
||||
|
||||
**关键修改项**:
|
||||
```bash
|
||||
# 切换到项目目录
|
||||
cd /path/to/your/bot
|
||||
|
||||
* **数据库与服务地址**:
|
||||
* 确保 `napcat_ws` 和 `redis` 部分的地址、端口和密码都指向您的生产服务器，而不是本地开发环境。
|
||||
# 创建虚拟环境 (强烈建议)
|
||||
python3.14 -m venv venv
|
||||
source venv/bin/activate
|
||||
|
||||
|
||||
|
||||
## 2. 使用进程守护工具
|
||||
|
||||
直接在终端中运行 `python main.py` 适用于开发，但在生产环境中，如果终端关闭或程序意外崩溃，机器人就会下线。
|
||||
|
||||
为了确保机器人能够 7x24 小时稳定运行，您应该使用**进程守护工具**。
|
||||
|
||||
### 推荐工具
|
||||
|
||||
* **PM2 (Node.js)**: 尽管是 Node.js 工具，但 PM2 提供了强大的 Python 进程管理功能，包括崩溃自启、日志管理和性能监控。
|
||||
* **Supervisor (Python)**: 一个纯 Python 实现的进程控制系统，配置简单，稳定可靠。
|
||||
* **Systemd (Linux)**: Linux 系统自带的服务管理器，可以创建系统服务来管理机器人进程。
|
||||
|
||||
### 使用 PM2 (示例)
|
||||
|
||||
1. **安装 PM2**:
|
||||
```bash
|
||||
npm install -g pm2
|
||||
```
|
||||
|
||||
2. **创建生态系统文件**:
|
||||
在项目根目录创建一个 `ecosystem.config.js` 文件：
|
||||
|
||||
```javascript
|
||||
// ecosystem.config.js
|
||||
module.exports = {
|
||||
apps: [
|
||||
{
|
||||
name: 'neo-bot', // 应用名称
|
||||
script: 'main.py', // 启动脚本
|
||||
interpreter: '/path/to/your/venv/bin/python', // 指定虚拟环境的 Python 解释器
|
||||
env: {
|
||||
'APP_ENV': 'production', // 设置环境变量
|
||||
},
|
||||
},
|
||||
],
|
||||
};
|
||||
```
|
||||
**注意**: 请务必将 `interpreter` 路径修改为您服务器上虚拟环境的实际路径。
|
||||
|
||||
3. **启动应用**:
|
||||
```bash
|
||||
pm2 start ecosystem.config.js
|
||||
```
|
||||
|
||||
4. **常用 PM2 命令**:
|
||||
* `pm2 list`: 查看所有应用状态
|
||||
* `pm2 logs neo-bot`: 查看日志
|
||||
* `pm2 restart neo-bot`: 重启应用
|
||||
* `pm2 stop neo-bot`: 停止应用
|
||||
* `pm2 startup`: 设置开机自启
|
||||
|
||||
## 3. 禁用热重载
|
||||
|
||||
热重载功能在开发时非常有用，但在生产环境中会带来不必要的性能开销和潜在的不稳定性。
|
||||
|
||||
在部署前，建议您在 `main.py` 中**注释掉**或移除与 `watchdog` 相关的文件监控代码。
|
||||
|
||||
**修改 `main.py`**:
|
||||
|
||||
```python
|
||||
# main.py
|
||||
|
||||
async def main():
|
||||
# ...
|
||||
|
||||
# 生产环境中禁用文件监控
|
||||
# loop = asyncio.get_running_loop()
|
||||
# event_handler = PluginReloadHandler(loop)
|
||||
# observer = Observer()
|
||||
# if os.path.exists(plugin_path):
|
||||
# observer.schedule(event_handler, plugin_path, recursive=True)
|
||||
# observer.start()
|
||||
# logger.info(f"已启动插件热重载监控: {plugin_path}")
|
||||
|
||||
try:
|
||||
# ...
|
||||
finally:
|
||||
# if observer.is_alive():
|
||||
# observer.stop()
|
||||
# observer.join()
|
||||
# 安装依赖
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
遵循以上步骤，您就可以将 NEO Bot 机器人稳定、高效地部署在生产服务器上。
|
||||
### c. 编译核心模块 (可选，但强烈建议)
|
||||
|
||||
为了极致性能，把核心模块编译成 C 扩展。
|
||||
|
||||
```bash
|
||||
python setup_mypyc.py build_ext --inplace
|
||||
```
|
||||
|
||||
## 2. 使用进程管理器
|
||||
|
||||
你想直接 `python main.py` 然后关掉 SSH？那机器人也跟着停了。必须用进程管理器来守护它。
|
||||
|
||||
这里推荐用 `pm2`，虽然是 Node.js 的工具，但管 Python 程序一样好用。
|
||||
|
||||
### a. 安装 pm2
|
||||
|
||||
```bash
|
||||
# 你需要先装 Node.js 和 npm
|
||||
npm install pm2 -g
|
||||
```
|
||||
|
||||
### b. 启动 Bot
|
||||
|
||||
在项目根目录，创建一个 `ecosystem.config.js` 文件：
|
||||
|
||||
```javascript
|
||||
module.exports = {
|
||||
apps : [{
|
||||
name : "neobot",
|
||||
script : "main.py",
|
||||
interpreter: "/path/to/your/bot/venv/bin/python", // 指定虚拟环境里的 python
|
||||
max_memory_restart: "500M", // 内存超过 500M 自动重启
|
||||
env: {
|
||||
"PYTHONUNBUFFERED": "1" // 禁用 python 输出缓冲，日志能实时看
|
||||
}
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
然后启动：
|
||||
|
||||
```bash
|
||||
pm2 start ecosystem.config.js
|
||||
```
|
||||
|
||||
### c. 常用 pm2 命令
|
||||
|
||||
```bash
|
||||
pm2 list # 查看所有进程状态
|
||||
pm2 logs neobot # 查看 neobot 的实时日志
|
||||
pm2 restart neobot# 重启 neobot
|
||||
pm2 stop neobot # 停止 neobot
|
||||
pm2 delete neobot # 删除 neobot
|
||||
```
|
||||
|
||||
## 3. 配置 NapCatQQ
|
||||
|
||||
最后一步，修改 NapCatQQ 的配置文件，让它把消息推送到你的服务器上。
|
||||
|
||||
找到 NapCatQQ 的 `config/onebot11.json` 文件，修改 `ws_reverse_servers` 部分：
|
||||
|
||||
```json
|
||||
"ws_reverse_servers": [
|
||||
{
|
||||
"url": "ws://你的服务器IP:8080/onebot/v11/ws",
|
||||
"access_token": "你的访问令牌"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
* `url`: 改成你服务器的 IP 和 `main.py` 里配置的端口。
|
||||
* `access_token`: 如果你在 `main.py` 里设置了 `ACCESS_TOKEN`，这里要保持一致。
|
||||
|
||||
改完后重启 NapCatQQ，Bot 应该就能收到消息了。
|
||||
|
||||
@@ -1,99 +1,90 @@
|
||||
# 插件开发：指令处理
|
||||
# 指令处理与参数解析
|
||||
|
||||
`@matcher.command()` 是插件开发中使用最频繁的装饰器。本节将深入介绍它的高级用法，帮助您构建功能更强大的指令。
|
||||
光会 `event.reply()` 只能写玩具。正经的插件，都得和用户传进来的参数打交道。
|
||||
|
||||
## 1. 获取指令参数
|
||||
## 1. 获取原始参数
|
||||
|
||||
在很多场景下，指令都需要接收用户提供的参数，例如 `/weather 北京`。框架会自动解析这些参数，并通过函数签名注入到您的处理器中。
|
||||
|
||||
您只需要在处理函数的参数列表中添加一个名为 `args` 的参数，并指定其类型为 `list[str]`。
|
||||
最简单粗暴的方式，就是直接在处理器函数里声明 `args: str`。
|
||||
|
||||
```python
|
||||
# plugins/weather.py
|
||||
from core.managers.command_manager import matcher
|
||||
from models.events.message import MessageEvent
|
||||
|
||||
@matcher.command("weather")
|
||||
async def handle_weather_command(event: MessageEvent, args: list[str]):
|
||||
"""
|
||||
处理 /weather 指令
|
||||
:param event: 消息事件对象
|
||||
:param args: 用户发送的参数列表 (已按空格分割)
|
||||
"""
|
||||
@matcher.command("echo")
|
||||
async def handle_echo(event: MessageEvent, args: str):
|
||||
# 如果用户发送 /echo hello world
|
||||
# args 的值就是 "hello world"
|
||||
if not args:
|
||||
await event.reply("请输入城市名，例如：/weather 北京")
|
||||
return
|
||||
|
||||
# args[0] 就是 "北京"
|
||||
city = args[0]
|
||||
|
||||
# ...后续逻辑...
|
||||
await event.reply(f"正在查询 {city} 的天气...")
|
||||
await event.reply("你啥也没说啊。")
|
||||
else:
|
||||
await event.reply(f"你说了：{args}")
|
||||
```
|
||||
|
||||
* 如果用户发送 `/weather 北京`，`args` 将是 `['北京']`。
|
||||
* 如果用户发送 `/weather 上海 浦东`，`args` 将是 `['上海', '浦东']`。
|
||||
* 如果用户只发送 `/weather`，`args` 将是一个空列表 `[]`。
|
||||
`args` 就是去掉命令本身后，后面跟着的**一整坨字符串**。
|
||||
|
||||
## 2. 设置指令别名
|
||||
## 2. 自动解析参数 (推荐)
|
||||
|
||||
同一个功能，用户可能习惯使用不同的指令名称来触发，例如 `天气` 和 `weather`。`@matcher.command()` 允许您为一个处理器设置多个别名。
|
||||
一整坨字符串用起来太费劲了，还得自己 `split()`。框架提供了更高级的玩法：**参数自动解析**。
|
||||
|
||||
只需在装饰器中传入多个名称即可：
|
||||
你只需要在函数签名里，用类型提示声明你想要的参数，框架会像 FastAPI 一样，自动帮你解析和注入。
|
||||
|
||||
### a. 基础用法
|
||||
|
||||
```python
|
||||
@matcher.command("weather", "天气")
|
||||
async def handle_weather_command(event: MessageEvent, args: list[str]):
|
||||
# ...
|
||||
```
|
||||
|
||||
现在，用户发送 `/weather 北京` 或 `/天气 北京` 都可以触发这个函数。
|
||||
|
||||
## 3. 权限控制
|
||||
|
||||
某些敏感指令只希望特定权限的用户才能执行，例如 `/reload` (重载插件) 或 `/ban` (禁言用户)。
|
||||
|
||||
`@matcher.command()` 装饰器提供了一个 `permission` 参数，可以轻松实现权限控制。
|
||||
|
||||
首先，从 `permission_manager` 导入预设的权限等级：
|
||||
|
||||
```python
|
||||
from core.managers.permission_manager import ADMIN, OP, USER
|
||||
```
|
||||
|
||||
然后，在装饰器中指定所需的权限：
|
||||
|
||||
```python
|
||||
# plugins/admin_tools.py
|
||||
from core.managers.command_manager import matcher
|
||||
from core.managers.permission_manager import ADMIN
|
||||
from models.events.message import MessageEvent
|
||||
|
||||
__plugin_meta__ = {
|
||||
"name": "管理工具",
|
||||
"description": "提供机器人管理功能",
|
||||
"usage": "/reload - 重载所有插件 (仅管理员)",
|
||||
}
|
||||
|
||||
@matcher.command("reload", permission=ADMIN)
|
||||
async def handle_reload_command(event: MessageEvent):
|
||||
"""
|
||||
重载所有插件，仅限管理员使用。
|
||||
"""
|
||||
# 这里的逻辑只有在权限检查通过后才会执行
|
||||
await event.reply("正在重载所有插件...")
|
||||
# ... 执行重载逻辑 ...
|
||||
@matcher.command("add")
|
||||
async def handle_add(event: MessageEvent, a: int, b: int):
|
||||
# 如果用户发送 /add 10 20
|
||||
# 框架会自动把 "10" 转成整数 10，注入给 a
|
||||
# 把 "20" 转成整数 20，注入给 b
|
||||
result = a + b
|
||||
await event.reply(f"计算结果是：{result}")
|
||||
```
|
||||
|
||||
* **工作原理**: 在调用您的处理函数之前，`CommandManager` 会自动调用 `PermissionManager` 来检查用户的权限。
|
||||
* **失败响应**: 如果用户权限不足，框架会自动回复一条权限不足的消息（该消息内容可在 `config.toml` 中配置），并且**不会**执行您的处理函数。
|
||||
**它是怎么工作的？**
|
||||
|
||||
可用的权限等级：
|
||||
框架会按顺序把 `args` 字符串用空格分割，然后尝试把分割后的每一块，转换成你声明的参数类型。
|
||||
|
||||
* `ADMIN`: 机器人超级管理员。
|
||||
* `OP`: 管理员（Operator），权限低于 `ADMIN`。
|
||||
* `USER`: 普通用户，默认权限。
|
||||
* `/add 10 20` -> `args` 是 `"10 20"` -> 分割成 `["10", "20"]`
|
||||
* 第一块 `"10"` -> 尝试转成 `int` -> 成功，`a = 10`
|
||||
* 第二块 `"20"` -> 尝试转成 `int` -> 成功，`b = 20`
|
||||
|
||||
权限关系是 `ADMIN > OP > USER`。设置 `permission=OP` 意味着 `OP` 和 `ADMIN` 都可以使用该指令。
|
||||
### b. 处理可选参数和默认值
|
||||
|
||||
通过组合使用参数处理、别名和权限控制，您可以构建出既灵活又安全的指令来满足各种复杂的需求。
|
||||
你可以像普通 Python 函数一样，给参数提供默认值。
|
||||
|
||||
```python
|
||||
from typing import Optional
|
||||
|
||||
@matcher.command("greet")
|
||||
async def handle_greet(event: MessageEvent, name: str, title: Optional[str] = "先生"):
|
||||
# 例 1: /greet 张三
|
||||
# name = "张三", title = "先生" (默认值)
|
||||
|
||||
# 例 2: /greet 李四 女士
|
||||
# name = "李四", title = "女士"
|
||||
|
||||
await event.reply(f"你好，{name} {title}！")
|
||||
```
|
||||
|
||||
### c. 贪婪的最后一个参数
|
||||
|
||||
有时候，最后一个参数可能包含空格，比如 `/say hello world`。默认情况下，`hello` 会被解析给第一个参数，`world` 会被解析给第二个。
|
||||
|
||||
如果你想让最后一个参数“吃掉”所有剩下的内容，可以用 `...` 作为默认值（这是一个特殊的标记）。
|
||||
|
||||
```python
|
||||
@matcher.command("say")
|
||||
async def handle_say(event: MessageEvent, target_user: str, content: str = ...):
|
||||
# 例: /say 张三 早上好，吃了没？
|
||||
# target_user = "张三"
|
||||
# content = "早上好，吃了没？"
|
||||
|
||||
await event.reply(f"正在对 {target_user} 说：{content}")
|
||||
```
|
||||
|
||||
## 3. 更复杂的解析：依赖注入
|
||||
|
||||
如果你的参数不是简单的 `int` 或 `str`，或者你需要更复杂的解析逻辑（比如 `@某人`），请参考 `FastAPI` 的依赖注入系统，我们用了同一套逻辑。
|
||||
|
||||
@@ -1,51 +1,10 @@
|
||||
# 插件开发：基础指南
|
||||
# 插件开发入门
|
||||
|
||||
在 NEO Bot Framework 中，几乎所有的功能都是通过**插件**来实现的。框架提供了一个强大而简单的插件系统，让您可以专注于功能逻辑的实现。
|
||||
写插件是给 NEO Bot 添加功能的唯一方式。这玩意儿很简单，一个 Python 文件就是一个插件。
|
||||
|
||||
## 插件是什么？
|
||||
## 1. 创建你的第一个插件
|
||||
|
||||
一个插件本质上就是一个位于 `plugins/` 目录下的独立 Python 文件 (`.py`)。
|
||||
|
||||
框架会在启动时自动扫描并加载这个目录下的所有文件作为插件。
|
||||
|
||||
## 🔥 热重载工作流
|
||||
|
||||
在开始编写插件之前，了解框架的**热重载**机制至关重要，它能极大地提升您的开发效率。
|
||||
|
||||
1. **启动机器人**: 首先，在您的终端中运行 `python main.py` 并保持其运行状态。
|
||||
2. **创建或修改插件**: 在 `plugins/` 目录下创建新的 `.py` 文件，或者修改一个已有的插件文件。
|
||||
3. **保存文件**: 当您保存文件时，框架会自动检测到文件变更。
|
||||
4. **自动重载**: 控制台会显示 `插件重载完成` 的日志，这意味着您的新代码已经生效，无需重启整个程序。
|
||||
|
||||
## 创建您的第一个插件
|
||||
|
||||
让我们来创建一个经典的 "Hello World" 插件。
|
||||
|
||||
### 1. 创建文件
|
||||
|
||||
在 `plugins/` 目录下创建一个新文件，命名为 `hello.py`。
|
||||
|
||||
### 2. 定义插件元数据 (`__plugin_meta__`)
|
||||
|
||||
为了让框架能够识别您的插件信息（例如在 `/help` 命令中显示），您需要在文件顶部定义一个名为 `__plugin_meta__` 的特殊字典。
|
||||
|
||||
```python
|
||||
# plugins/hello.py
|
||||
|
||||
__plugin_meta__ = {
|
||||
"name": "你好世界",
|
||||
"description": "一个简单的插件，用于回复 'Hello, World!'。",
|
||||
"usage": "/hello - 发送问候。",
|
||||
}
|
||||
```
|
||||
|
||||
* `name`: 插件的名称。
|
||||
* `description`: 插件功能的简短描述。
|
||||
* `usage`: 插件的使用方法说明。
|
||||
|
||||
### 3. 编写处理器
|
||||
|
||||
现在，让我们来编写一个响应 `/hello` 指令的函数。我们需要从框架中导入 `matcher` 和事件类型。
|
||||
在 `plugins/` 目录下，新建一个 `hello.py` 文件。
|
||||
|
||||
```python
|
||||
# plugins/hello.py
|
||||
@@ -53,36 +12,65 @@ __plugin_meta__ = {
|
||||
from core.managers.command_manager import matcher
|
||||
from models.events.message import MessageEvent
|
||||
|
||||
# __plugin_meta__ 是插件元信息，会在 /help 指令里显示
|
||||
__plugin_meta__ = {
|
||||
"name": "你好世界",
|
||||
"description": "一个简单的插件，用于回复 'Hello, World!'。",
|
||||
"usage": "/hello - 发送问候。",
|
||||
"description": "一个简单的示例插件",
|
||||
"usage": "/hello - 发送你好"
|
||||
}
|
||||
|
||||
# 使用 @matcher.command 装饰器来注册一个指令
|
||||
@matcher.command("hello")
|
||||
async def handle_hello_command(event: MessageEvent):
|
||||
# @matcher.command() 装饰器注册一个命令
|
||||
# "hello" 是命令名，aliases 是别名
|
||||
@matcher.command("hello", aliases=["hi", "你好"])
|
||||
async def handle_hello(event: MessageEvent):
|
||||
"""
|
||||
当用户发送 /hello 时，此函数将被调用。
|
||||
处理 /hello 命令
|
||||
"""
|
||||
# 使用 event.reply() 方法可以快速回复消息到来源地
|
||||
await event.reply("Hello, World!")
|
||||
# event.reply() 是一个快捷方法，可以直接回复消息
|
||||
await event.reply(f"你好，{event.sender.nickname}！")
|
||||
|
||||
```
|
||||
|
||||
### 4. 测试插件
|
||||
## 2. 加载插件
|
||||
|
||||
1. 确保 `python main.py` 正在运行。
|
||||
2. 保存 `plugins/hello.py` 文件。您应该会在控制台看到插件重载的日志。
|
||||
3. 在任何一个机器人所在的群聊或私聊中，发送 `/hello`。
|
||||
4. 机器人应该会回复 `Hello, World!`。
|
||||
不用你动手，NEO Bot 启动时会自动加载 `plugins/` 目录下的所有 `.py` 文件。
|
||||
|
||||
恭喜！您已经成功创建并运行了您的第一个插件。
|
||||
如果你是在 Bot 运行时新增或修改了插件，只需要在控制台输入 `reload` 命令，或者让管理员在群里发 `/reload`，就能热重载所有插件。
|
||||
|
||||
## 插件的最佳实践
|
||||
## 3. 测试插件
|
||||
|
||||
* **保持独立**: 尽量让每个插件文件只负责一项相关的功能。
|
||||
* **清晰命名**: 为您的插件文件和处理函数选择清晰、描述性的名称。
|
||||
* **善用模型**: 充分利用 `models` 中定义的事件和消息段类型，以获得完整的类型提示和代码补全支持。
|
||||
* **异步优先**: 框架是基于 `asyncio` 构建的。对于任何 I/O 密集型操作（如网络请求、文件读写），请务必使用 `async/await` 语法，以避免阻塞事件循环。
|
||||
现在，去群里或者私聊给 Bot 发送：
|
||||
|
||||
现在您已经掌握了插件的基础，可以继续学习更高级的主题，例如[如何处理带参数的指令](./command-handling.md)。
|
||||
* `/hello`
|
||||
* `/hi`
|
||||
* `/你好`
|
||||
|
||||
Bot 应该会回复你：“你好，[你的昵称]！”
|
||||
|
||||
## 插件剖析
|
||||
|
||||
### `__plugin_meta__`
|
||||
|
||||
这个字典不是必须的，但强烈建议写上。它定义了插件的元信息，主要给 `/help` 命令用。
|
||||
|
||||
* `name`: 插件叫啥。
|
||||
* `description`: 这插件是干嘛的。
|
||||
* `usage`: 怎么用，写上具体的指令和说明。
|
||||
|
||||
### `@matcher.command()`
|
||||
|
||||
这是最核心的装饰器，用来注册一个命令处理器。
|
||||
|
||||
* **第一个参数**: `name` (str)，命令的主名。
|
||||
* `aliases`: `List[str]`，命令的别名列表。
|
||||
* `permission`: `int`，执行该命令所需的权限等级，默认为 `USER` (所有人可用)。可以是 `ADMIN`, `OP`。
|
||||
|
||||
### 处理器函数
|
||||
|
||||
被 `@matcher.command()` 装饰的函数就是处理器。它必须是一个 `async` 异步函数。
|
||||
|
||||
* **参数**: 框架会自动往里注入参数，你只需要用类型提示声明你需要什么。
|
||||
* `event: MessageEvent`: 这是最常用的，包含了消息的所有信息，比如发送者、群号、消息内容等。
|
||||
* `args: str`: 如果命令有参数（比如 `/echo hello world`），`args` 就是 `hello world` 这部分字符串。
|
||||
|
||||
就这么简单，一个最基础的插件就写完了。
|
||||
|
||||
@@ -1,70 +1,48 @@
|
||||
# 项目结构解析
|
||||
# 项目结构
|
||||
|
||||
理解 NEO Bot Framework 的项目结构是高效开发的第一步。本节将详细介绍每个主要目录和文件的用途。
|
||||
了解项目里每个文件夹是干嘛的，能让你更快找到代码。
|
||||
|
||||
```
|
||||
.
|
||||
├── core/ # 框架核心代码
|
||||
│ ├── api/ # OneBot v11 API 的 Mixin 封装
|
||||
│ ├── data/ # 核心模块的数据存储 (admin, permissions)
|
||||
│ ├── handlers/ # 底层事件处理器 (message, notice, request)
|
||||
│ ├── managers/ # 核心单例管理器 (command, permission, etc.)
|
||||
│ ├── utils/ # 通用工具 (logger, singleton, etc.)
|
||||
│ ├── bot.py # Bot 核心类，提供 API 调用接口
|
||||
│ ├── config_loader.py # TOML 配置文件加载器
|
||||
│ └── ws.py # WebSocket 底层通信模块
|
||||
├── core/ # 核心代码，别乱动
|
||||
│ ├── handlers/ # 底层事件处理器
|
||||
│ ├── managers/ # 全局单例管理器
|
||||
│ ├── utils/ # 工具函数
|
||||
│ └── ws.py # WebSocket 连接实现
|
||||
├── data/ # 存放持久化数据
|
||||
│ ├── admin.json # 管理员列表
|
||||
│ └── permissions.json # 用户权限列表
|
||||
├── docs/ # 开发文档
|
||||
├── html/ # 静态网页文件 (用于 Web 仪表盘等)
|
||||
├── models/ # 数据模型 (事件, 消息段)
|
||||
│ ├── events/ # OneBot v11 事件的 Python 对象封装
|
||||
│ ├── message.py # 消息段 (MessageSegment) 的定义
|
||||
│ └── ...
|
||||
├── plugins/ # 功能插件目录
|
||||
├── venv/ # Python 虚拟环境 (推荐)
|
||||
├── .gitignore # Git 忽略文件配置
|
||||
├── config.toml # 主配置文件
|
||||
├── main.py # 项目启动入口
|
||||
└── requirements.txt # Python 依赖列表
|
||||
├── logs/ # 日志文件
|
||||
├── models/ # 数据模型
|
||||
│ └── events/ # OneBot 事件模型
|
||||
├── plugins/ # 你的插件都放这
|
||||
├── templates/ # 图片渲染用的网页模板
|
||||
├── venv/ # Python 虚拟环境
|
||||
├── .gitignore # Git 忽略配置
|
||||
├── main.py # 主入口文件
|
||||
├── requirements.txt # Python 依赖列表
|
||||
└── setup_mypyc.py # Mypyc 编译脚本
|
||||
```
|
||||
|
||||
## 顶层目录
|
||||
## 重点目录说明
|
||||
|
||||
### `core/`
|
||||
|
||||
这是框架的心脏，包含了所有核心逻辑。**通常情况下，您不需要修改此目录下的代码**，只需了解其工作原理即可。
|
||||
这是框架的心脏。除非你知道自己在干嘛，否则别碰这里面的东西。大部分功能都由 `managers` 里的管理器提供，你只需要 `import` 它们就行。
|
||||
|
||||
* `api/`: 将 OneBot v11 的 API 按功能（如 `message`, `group`）拆分为多个 `Mixin` 类，最终由 `bot.py` 继承，提供了清晰的 API 结构。
|
||||
* `data/`: 存放核心模块所需的数据文件，例如 `admin.json` 和 `permissions.json`。
|
||||
* `handlers/`: 定义了最底层的事件处理器，如 `MessageHandler`，负责从 `ws.py` 接收原始事件并进行初步处理和分发。
|
||||
* `managers/`: 包含一系列全局单例管理器，是框架功能的核心实现。例如，`CommandManager` 负责指令注册与匹配，`PermissionManager` 负责权限控制。
|
||||
* `utils/`: 提供被广泛使用的工具类，如 `logger` (日志)、`singleton` (单例模式基类)。
|
||||
* `bot.py`: 定义了 `Bot` 类，这是插件开发者最常与之交互的对象，用于调用所有 OneBot API。
|
||||
* `config_loader.py`: 负责解析 `config.toml` 文件，并提供一个全局的 `global_config` 对象。
|
||||
* `config_models.py`: 使用 Pydantic 定义了配置文件的结构和类型验证。
|
||||
* `ws.py`: 实现了与 OneBot v11 实现端的 WebSocket 连接、心跳、重连和消息收发。
|
||||
### `data/`
|
||||
|
||||
### `docs/`
|
||||
|
||||
存放项目的所有开发文档。
|
||||
|
||||
### `html/`
|
||||
|
||||
用于存放未来 Web 仪表盘或其他 Web 功能所需的静态资源（HTML, CSS, JavaScript）。
|
||||
|
||||
### `models/`
|
||||
|
||||
定义了将 OneBot v11 的 JSON 数据转换为易于使用的 Python 对象。
|
||||
|
||||
* `events/`: 将所有上报的事件（如 `MessageEvent`, `GroupIncreaseNoticeEvent`）封装为带有类型提示的类。
|
||||
* `message.py`: 提供了 `MessageSegment` 类，用于构建复杂的消息内容（如 @某人、发送图片）。
|
||||
存放一些 JSON 格式的数据。管理员和用户权限默认存在这里。如果你用 Redis，这些文件会作为备份。
|
||||
|
||||
### `plugins/`
|
||||
|
||||
这是**插件开发者最关心的目录**。所有机器人的功能都以独立的 `.py` 文件形式存放在这里。框架会自动加载此目录下的所有插件，并支持热重载。
|
||||
**这是你最常待的地方**。你写的所有插件（`.py` 文件）都扔在这个目录里。Bot 启动时会自动加载这里的所有插件。
|
||||
|
||||
## 顶层文件
|
||||
### `templates/`
|
||||
|
||||
* `.gitignore`: 配置 Git 应忽略的文件和目录，如 `__pycache__`、`venv` 等。
|
||||
* `config.toml`: 项目的主配置文件，用于设置机器人、数据库、API 等所有可变参数。
|
||||
* `main.py`: 项目的启动入口脚本。它负责初始化日志、加载插件、启动 WebSocket 连接和文件监控（用于热重载）。
|
||||
* `requirements.txt`: 列出了项目运行所需的所有 Python 第三方库及其版本。
|
||||
如果你要用 `ImageManager` 画图，就需要把 HTML 模板文件放在这里。
|
||||
|
||||
### `main.py`
|
||||
|
||||
程序的入口。负责加载配置、初始化管理器、启动 WebSocket 连接和 FastAPI 服务。
|
||||
|
||||
Reference in New Issue
Block a user