Dev (#36)

* 滚木

* feat: 重构核心架构，增强类型安全与插件管理

本次提交对核心模块进行了深度重构，引入 Pydantic 增强配置管理的类型安全性，并全面优化了插件管理系统。

主要变更详情：

1. 核心架构与配置
   - 重构配置加载模块：引入 Pydantic 模型 (`core/config_models.py`)，提供严格的配置项类型检查、验证及默认值管理。
   - 统一模块结构：规范化模块导入路径，移除冗余的 `__init__.py` 文件，提升项目结构的清晰度。
   - 性能优化：集成 Redis 缓存支持 (`RedisManager`)，有效降低高频 API 调用开销，提升响应速度。

2. 插件系统升级
   - 实现热重载机制：新增插件文件变更监听功能，支持开发过程中自动重载插件，提升开发效率。
   - 优化生命周期管理：改进插件加载与卸载逻辑，支持精确卸载指定插件及其关联的命令、事件处理器和定时任务。

3. 功能特性增强
   - 新增媒体 API：引入 `MediaAPI` 模块，封装图片、语音等富媒体资源的获取与处理接口。
   - 完善权限体系：重构权限管理系统，实现管理员与操作员的分级控制，支持更细粒度的命令权限校验。

4. 代码质量与稳定性
   - 全面类型修复：解决 `mypy` 静态类型检查发现的大量类型错误（包括 `CommandManager`、`EventFactory` 及 `Bot` API 签名不匹配问题）。
   - 增强错误处理：优化消息处理管道的异常捕获机制，完善关键路径的日志记录，提升系统运行稳定性。

* feat: 添加测试用例并优化代码结构

refactor(permission_manager): 调整初始化顺序和逻辑
fix(admin_manager): 修复初始化逻辑和目录创建问题
feat(ws): 优化Bot实例初始化条件
feat(message): 增强MessageSegment功能并添加测试
feat(events): 支持字符串格式的消息解析
test: 添加核心功能测试用例
refactor(plugin_manager): 改进插件路径处理
style: 清理无用导入和代码
chore: 更新依赖项

* refactor(handler): 移除TYPE_CHECKING并直接导入Bot类

简化类型注解，直接导入Bot类而非使用TYPE_CHECKING条件导入，提高代码可读性和维护性

* fix(command_manager): 修复插件卸载时元信息移除不精确的问题

修复 CommandManager 中 unload_plugin 方法移除插件元信息时使用 startswith 导致可能误删其他插件的问题，改为精确匹配
同时调整相关测试用例验证精确匹配行为

* refactor: 清理未使用的导入和更新文档结构

docs: 添加config_models.py到项目结构文档
docs: 调整数据目录位置到core/data下
docs: 更新权限管理器文档描述

* 文档更新

* 更新thpic插件 支持一次返回多张图

* feat: 添加测试覆盖率并修复相关问题

refactor(redis_manager): 移除冗余的ConnectionError处理
refactor(event_handler): 优化Bot类型注解
refactor(factory): 移除未使用的GroupCardNoticeEvent

test: 添加全面的单元测试覆盖
- 添加test_import.py测试模块导入
- 添加test_debug.py测试插件加载调试
- 添加test_plugin_error.py测试错误处理
- 添加test_config_loader.py测试配置加载
- 添加test_redis_manager.py测试Redis管理
- 添加test_bot.py测试Bot功能
- 扩展test_models.py测试消息模型
- 添加test_plugin_manager_coverage.py测试插件管理
- 添加test_executor.py测试代码执行器
- 添加test_ws.py测试WebSocket
- 添加test_api.py测试API接口
- 添加test_core_managers.py测试核心管理模块

fix(plugin_manager): 修复插件加载日志变量问题

覆盖率已到达86%（忽略插件）

* 更新/help指令，现在会发送图片

* feat(help): 重构帮助系统为图片渲染模式

添加浏览器管理器和图片管理器，用于通过 Playwright 渲染帮助菜单为图片
重构命令管理器以支持图片缓存和同步功能
添加 HTML 模板用于帮助菜单渲染

* build: 更新依赖文件 requirements.txt

* build: 更新依赖文件

* feat: 添加性能优化和架构文档，更新依赖和核心模块

refactor(browser_manager): 实现页面池机制以提升性能
refactor(image_manager): 添加模板缓存并集成页面池
refactor(bili_parser): 迁移到异步HTTP请求并实现会话复用
docs: 新增性能优化、架构设计和最佳实践文档
chore: 更新requirements.txt添加新依赖

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

重构所有文档内容，使用更简洁直接的语言风格
更新架构、插件开发、部署等核心文档
优化代码示例和图表说明
统一术语和格式规范

* docs: 更新文档内容，简化语言并修正格式

- 简化插件开发指南中的描述，移除冗余内容
- 调整部署文档中的Python版本说明
- 优化最佳实践文档的措辞和格式
- 更新性能优化文档，删除不准确的数据
- 重构核心概念文档，使用更简洁的语言
- 修正README中的项目描述和技术栈说明
- 更新快速上手文档，简化安装步骤
- 调整事件流转文档的描述方式
- 简化架构文档内容
- 更新指令处理文档，添加参数注入示例
- 优化单例管理器文档的表述

---------

Co-authored-by: baby20162016 <2185823427@qq.com>

docs/core-concepts/event-flow.md

@@ -1,8 +1,8 @@
 # 核心概念：事件流转
 
-在 NEO Bot Framework 中，所有交互都由**事件**驱动。理解一个事件从被接收到最终被处理的完整流程，是掌握框架工作原理的关键。
+NEO Bot 的核心就是**事件驱动**。搞懂一个事件从哪来、到哪去，你就懂了一大半。
 
-本节将以一个用户发送 `/echo hello` 的群聊消息为例，详细拆解其在框架内部的流转路径。
+下面就拿 `/echo hello` 举例
 
 ## 事件流转图
 
@@ -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,42 +59,42 @@ graph TD
 
 ### 1. 接收 WebSocket 消息 (`core/ws.py`)
 
-*   当用户在 QQ 群里发送消息时，OneBot v11 实现端（如 NapCatQQ）会将其打包成一个 JSON 格式的数据，并通过 WebSocket 连接发送给框架。
-*   `core/ws.py` 中的 `_listen_loop` 方法持续监听连接，接收到这个原始的 JSON 字符串。
+*   你在群里发了条消息，OneBot (比如 NapCatQQ) 就会把它打包成一个 JSON，通过 WebSocket 扔给 Bot。
+*   `core/ws.py` 里的 `_listen_loop` 一直在那蹲着，收到这个 JSON 字符串。
 
-### 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` 对象。
+*   这时候是python对象了，有属性有方法，感觉很方便。。。
 
-### 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` 传进去。
+*   这时候就是你写的代码在跑了。你想干啥都行。。。
 
-### 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" 发到了群里。
+*   恩。。。
 
-至此，一个完整的事件流转闭环就完成了。理解这个流程后，您就能明白框架是如何将底层的网络通信与高层的插件逻辑解耦，并为开发者提供便捷接口的。
+至此，一个完整的事件流转闭环就完成了。理解这个流程后，您就能明白框架是如何为开发者提供便捷接口的。