refactor(core): 重构核心模块结构并添加开发文档

将核心模块按功能重新组织为更清晰的结构，包括 managers、handlers 和 utils 目录
添加完整的开发文档，涵盖快速开始、项目结构、核心概念和插件开发指南
更新所有相关模块的导入路径以匹配新的结构
将单例模式实现提取到单独的 singleton.py 文件

docs/core-concepts/event-flow.md

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

docs/core-concepts/singleton-managers.md

@@ -0,0 +1,89 @@
+# 核心概念：单例管理器
+
+在 `core/managers/` 目录下，存放着一系列全局唯一的**管理器（Managers）**。它们是 NEO Bot Framework 功能的核心实现，负责处理事件、管理权限、加载插件等关键任务。
+
+理解这些管理器的职责，有助于您更好地利用框架提供的能力，并进行更高级的开发。
+
+## 设计模式：单例 (Singleton)
+
+框架中所有的管理器都采用了**单例设计模式**。这意味着在整个应用程序的生命周期中，每个管理器类只会存在一个实例。
+
+**为什么使用单例？**
+
+*   **全局访问点**: 任何模块（尤其是插件）都可以方便地导入并使用同一个管理器实例，无需手动传递。
+*   **状态共享**: 管理器内部维护的状态（如已注册的命令、用户权限列表）是全局共享和一致的。
+*   **资源统一管理**: 对于像 Redis 连接这样的资源，单例模式确保了全局只有一个连接池，避免了资源的浪费和冲突。
+
+框架在 `core/utils/singleton.py` 中提供了一个 `Singleton` 基类，所有管理器都继承自它，以轻松实现单例模式。
+
+## 核心管理器介绍
+
+### 1. `CommandManager` (全局实例: `matcher`)
+
+*   **文件**: `core/managers/command_manager.py`
+*   **全局实例**: `from core.managers.command_manager import matcher`
+*   **核心职责**:
+    *   **事件处理中枢**: 它是事件流转的核心，负责接收所有类型的事件，并将其分发给相应的底层处理器。
+    *   **装饰器提供者**: 为插件提供了 `@matcher.command()`, `@matcher.on_notice()` 等一系列装饰器，用于注册事件处理器。
+    *   **指令匹配**: 内部维护了一个指令注册表，能够根据消息内容匹配到对应的处理函数。
+
+`matcher` 是插件开发者最常打交道的管理器。
+
+### 2. `PermissionManager` (全局实例: `permission_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 缓存之间的数据同步，确保管理员列表的一致性和高效查询。
+
+### 4. `PluginManager`
+
+*   **文件**: `core/managers/plugin_manager.py`
+*   **核心职责**:
+    *   **插件加载**: 负责扫描 `plugins/` 目录，导入所有合法的插件模块。
+    *   **元数据提取**: 读取插件文件中定义的 `__plugin_meta__` 字典，用于 `/help` 指令等功能。
+    *   **热重载支持**: `load_all_plugins` 函数被 `main.py` 中的文件监控服务调用，以实现插件的热重载。
+
+此管理器通常在后台工作，开发者较少直接与其交互。
+
+### 5. `RedisManager` (全局实例: `redis_manager`)
+
+*   **文件**: `core/managers/redis_manager.py`
+*   **全局实例**: `from core.managers.redis_manager import redis_manager`
+*   **核心职责**:
+    *   **连接管理**: 负责初始化和管理与 Redis 服务器的异步连接。
+    *   **提供实例**: 通过 `redis_manager.redis` 属性，为其他模块提供一个可用的 `redis` 客户端实例。
+
+## 如何在插件中使用管理器
+
+在您的插件中，只需通过 `import` 语句导入相应管理器的全局实例即可使用。
+
+**示例**: 在插件中检查用户是否为管理员。
+
+```python
+# plugins/my_plugin.py
+
+from core.managers.command_manager import matcher
+from core.managers.permission_manager import permission_manager, ADMIN
+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("这是一个只有管理员能看到的秘密。")
+    else:
+        await event.reply("抱歉，您没有权限执行此命令。")
+```