Dev (#45)
* 滚木 * 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中的项目描述和技术栈说明 - 更新快速上手文档,简化安装步骤 - 调整事件流转文档的描述方式 - 简化架构文档内容 - 更新指令处理文档,添加参数注入示例 - 优化单例管理器文档的表述 * refactor(core): 优化权限管理和事件模型 - 重构 AdminManager 和 PermissionManager 以 Redis 为主要数据源 - 为所有事件模型添加 slots=True 提升性能 - 更新文档说明 Mypyc 编译注意事项 - 清理测试和调试文件 - 移动静态资源到 web_static 目录 * feat: 添加模块编译脚本和导出依赖功能 refactor(events): 移除数据类的slots参数以提升兼容性 build: 更新requirements.txt依赖列表 * docs: 更新性能优化文档并修复命令管理器帮助输出 更新性能优化相关文档,详细说明 Python 3.14 JIT 编译器的使用方法和原理,补充与 Mypyc 的互补策略。同时修复命令管理器中帮助信息的输出方式,移除图片发送仅保留文本输出。 调整部署文档结构,明确两种性能优化方案(AOT 和 JIT)的配置方法和适用场景。完善架构文档中关于 JIT 的原理和启用方式说明。 * feat(help): 重构帮助菜单界面并优化样式 refactor(bili_parser): 修复 API 响应 content-type 问题 fix(command_manager): 添加帮助图片获取的错误处理 docs(deployment): 简化部署文档并移除 JIT 相关内容 * feat: 新增自动同意请求插件和API文档 docs: 更新文档结构和内容 * refactor(scripts): 重构并优化脚本文件结构 feat(scripts): 添加Python环境检查脚本 feat(scripts): 增强依赖导出脚本功能 perf(plugins/bili_parser): 优化B站解析器性能和代码结构 style(plugins/bili_parser): 统一代码风格和常量命名 * fix(scripts): 修复编码问题并添加错误追踪 在compile_machine_code.py中添加utf-8编码设置以避免潜在编码问题 添加traceback.print_exc()以在编译失败时打印完整错误堆栈 更新.gitignore以忽略config.toml文件 * feat(性能分析): 实现性能分析工具模块并添加相关测试 添加性能分析工具模块,包括时间测量、内存分析和性能统计功能 添加测试文件和示例配置,完善性能分析工具的使用场景 在工具模块中实现单例装饰器并导出到__init__.py * feat(douyin_parser): 新增抖音视频解析插件 refactor(performance): 移除未使用的asyncio导入并优化性能测试 style(compile_modules): 修正字符串引号格式 chore: 删除废弃的编译脚本和临时文件 fix(bili_parser): 增强B站链接解析的健壮性 refactor(singleton): 重构单例模式实现 docs: 更新配置文件和事件模型注释 * feat: 添加抖音视频解析插件并优化代码结构 添加抖音视频解析插件,支持自动解析抖音分享链接并提取视频信息。优化现有代码结构,包括: - 重构单例模式实现 - 移除未使用的导入和文件 - 修复性能测试脚本中的异步调用 - 优化消息事件模型中的权限常量定义 - 改进编译脚本的错误处理 - 增强B站解析插件的稳定性 同时清理了多个废弃脚本和临时文件,提升代码可维护性。 * 1 * Delete core/data/temp/help_menu.png * fix(权限管理): 增强权限检查的类型安全并修复权限引用 修复权限检查中可能传入非Permission类型导致的错误,将echo插件的权限引用从MessageEvent.ADMIN迁移到Permission.ADMIN * redis取消tls * feat(github_parser): 添加GitHub仓库信息查询功能 - 新增github_parser插件,支持通过命令或自动解析链接查询GitHub仓库信息 - 添加github_repo.html模板用于渲染仓库信息图片 - 优化图片管理器支持高质量截图和CSS缩放 - 重构消息事件类权限常量定义方式 - 更新帮助页面样式为三列布局并优化响应式设计 * feat(web_parser): 新增通用web链接解析插件框架 refactor: 重构B站、抖音、GitHub解析器为模块化结构 fix(executor): 增强docker容器错误处理和回调稳定性 style(templates): 优化帮助页面和代码执行结果的样式 perf(web_parser): 添加API缓存和消息去重机制 docs: 更新插件元信息和注释 chore: 移除旧的独立解析器插件文件 * refactor(managers): 重构单例管理器实现并优化代码结构 feat(ws_pool): 新增 WebSocket 连接池实现 perf(json): 使用 orjson 替代标准 json 库提升性能 style: 清理未使用的导入和冗余代码 docs: 更新架构文档和开发规范 test: 添加 WebSocket 连接池测试用例 fix(plugins): 修复自动审批插件 API 调用参数格式 --------- Co-authored-by: baby20162016 <2185823427@qq.com> Co-authored-by: web vscode <youremail@example.com>
This commit is contained in:
@@ -54,3 +54,118 @@ graph LR
|
||||
别几把开多个实例。。。
|
||||
* **Browser Pool**: 浏览器页面提前开好,用完洗干净放回去
|
||||
* **Connection Pool**: Redis 和 HTTP 请求都用连接池
|
||||
|
||||
## 4. 技术栈全景
|
||||
|
||||
NEO Bot 的“骨架”是由一堆现代 Python 库和技术堆起来的。下面这张清单能让你一眼看清整个项目的技术选型。
|
||||
|
||||
### 编程语言与运行时
|
||||
* **Python 3.14**: 镀铬酸钾创项目的时候用的 Python 3.14 3.14兼容JIT,那就这样吧
|
||||
* **JIT (Just-In-Time)**: 启动时加 `-X jit` 参数,运行时把热点代码编译成机器码
|
||||
* **Mypyc (AOT)**: 核心模块(`core/ws.py`, `core/managers/*.py`)编译成C扩展,机器码运行
|
||||
|
||||
### 异步与网络
|
||||
* **asyncio**: Python 原生异步框架,所有 IO 操作都是非阻塞的
|
||||
* **uvloop (Linux)**: 替代 asyncio 默认事件循环,性能更高
|
||||
* **IOCP (Windows)**: Windows 上的高性能 IO 完成端口
|
||||
* **aiohttp**: 异步 HTTP 客户端/服务器,用于 API 请求和 WebSocket 通信
|
||||
* **websockets**: 纯粹的 WebSocket 客户端/服务器库
|
||||
* **Playwright**: 浏览器自动化工具,负责截图、页面渲染
|
||||
|
||||
### 数据与存储
|
||||
* **Redis**: 内存数据库,用于缓存帮助图片、会话状态等
|
||||
* **orjson**: Rust 编写的 JSON 序列化库,比标准 `json` 快很多
|
||||
* **Pydantic**: 数据验证与设置管理,配置文件、API 请求/响应都靠它
|
||||
|
||||
### 工具与工具链
|
||||
* **Loguru**: 结构化日志记录,输出漂亮且支持文件轮转
|
||||
* **Watchdog**: 文件系统监控,实现插件热重载
|
||||
* **Jinja2**: 模板引擎,渲染 HTML 页面然后转为图片
|
||||
* **Pillow**: 图像处理库,负责图片格式转换、尺寸调整
|
||||
* **BeautifulSoup4**: HTML 解析,B站、抖音等链接解析插件在用
|
||||
* **httpx**: 异步 HTTP 客户端,某些插件用它发请求
|
||||
|
||||
### 测试与开发
|
||||
* **Pytest**: 测试框架,写单元测试、集成测试
|
||||
* **Docker**: 容器化,沙箱执行用户代码时可能用到
|
||||
* **cryptography**: 加密解密,处理一些安全相关的操作
|
||||
|
||||
### 架构模式
|
||||
* **Singleton (单例)**: 全局唯一实例,所有管理器都是单例
|
||||
* **Connection Pool (连接池)**: Redis 连接、HTTP 会话都复用
|
||||
* **Plugin System (插件系统)**: 动态导入、装饰器注册,一个 `.py` 文件就是一个插件
|
||||
|
||||
## 5. Python 动态语言特性运用
|
||||
|
||||
Python 是一门“动态”语言,这意味着你可以在运行时做很多静态语言做不到的事情。NEO Bot 大量利用了这些特性,让框架变得灵活、易扩展。
|
||||
|
||||
### 装饰器 (Decorator)
|
||||
* **何用**: 给函数“贴上标签”,告诉框架这个函数是干什么的
|
||||
* **何处**:
|
||||
* `@matcher.command("echo")` – 注册一个消息指令
|
||||
* `@matcher.on_message()` – 注册一个通用消息处理器
|
||||
* `@matcher.on_notice()` – 注册一个通知事件处理器
|
||||
* **何原理**: 装饰器本质上是一个高阶函数,它接收被装饰的函数,然后把它“注册”到某个管理器里
|
||||
|
||||
### 动态导入 (Dynamic Import)
|
||||
* **何用**: 不需要在代码开头写死 `import`,运行时根据情况加载模块
|
||||
* **何处**: `PluginManager.load_all_plugins()` 用 `importlib.import_module()` 扫描 `plugins/` 目录,找到 `.py` 文件就导入
|
||||
* **何原理**: Python 的模块系统是完全动态的,`import` 语句实际上调用了 `__import__()` 函数
|
||||
|
||||
### 自省 (Introspection)
|
||||
* **何用**: 让代码能“看到”自己的结构,比如函数属于哪个模块、有哪些参数
|
||||
* **何处**:
|
||||
* `inspect.getmodule(func)` – 获取函数所在的模块名,用于记录插件来源
|
||||
* `func.__name__`, `func.__module__` – 获取函数名和模块名
|
||||
* **何原理**: Python 把几乎所有元信息都存在对象的 `__dict__` 里,你可以随时翻看
|
||||
|
||||
### 鸭子类型 (Duck Typing)
|
||||
* **何用**: “如果它走起来像鸭子,叫起来像鸭子,那它就是鸭子。”——不检查类型,只检查行为
|
||||
* **何处**:
|
||||
* 事件处理器不要求事件对象必须是某个类,只要它有 `post_type`、`user_id` 等属性就行
|
||||
* 插件不需要继承某个基类,只要它有 `__plugin_meta__` 字典就行
|
||||
* **何原理**: Python 的变量没有类型,类型是对象自己的事。只要对象有你需要的方法或属性,你就可以调用它
|
||||
|
||||
### 反射 (Reflection)
|
||||
* **何用**: 在运行时检查、修改对象的结构
|
||||
* **何处**:
|
||||
* `getattr(module, "__plugin_meta__")` – 获取插件的元数据字典
|
||||
* `hasattr(event, "raw_message")` – 检查事件对象是否有某个属性
|
||||
* `setattr()` – 动态设置属性(虽然用得少)
|
||||
* **何原理**: Python 的对象本质上就是字典(`__dict__`),`getattr`/`setattr` 就是对这个字典的操作
|
||||
|
||||
### 元编程 (Metaprogramming)
|
||||
* **何用**: 在代码运行时改变代码的行为
|
||||
* **何处**:
|
||||
* `Singleton` 基类重写 `__new__` 方法,控制实例创建,确保全局只有一个实例
|
||||
* 装饰器在函数定义时修改函数,给它添加额外逻辑
|
||||
* **何原理**: Python 的类也是对象(类型对象),你可以通过修改类来影响它所有实例的行为
|
||||
|
||||
### 上下文管理器 (Context Manager)
|
||||
* **何用**: 安全地获取和释放资源,比如文件、网络连接、浏览器页面
|
||||
* **何处**:
|
||||
* `async with browser_manager.get_page() as page:` – 从页面池获取一个页面,用完后自动放回
|
||||
* `async with aiohttp.ClientSession() as session:` – 发起 HTTP 请求后自动关闭会话
|
||||
* **何原理**: `__enter__`/`__exit__`(同步)或 `__aenter__`/`__aexit__`(异步)协议
|
||||
|
||||
### 描述符 (Descriptor)
|
||||
* **何用**: 控制属性访问的逻辑,比如把方法伪装成属性
|
||||
* **何处**:
|
||||
* `@property` – 把方法变成只读属性,比如 `PluginManager.command_manager`
|
||||
* `@property.setter` – 给属性设置值时的自定义逻辑
|
||||
* **何原理**: 描述符是一个实现了 `__get__`、`__set__` 或 `__delete__` 方法的类
|
||||
|
||||
### 猴子补丁 (Monkey Patching)
|
||||
* **何用**: 在运行时修改模块、类或对象,通常用于测试或修复第三方库
|
||||
* **何处**: 测试中可能会用 `unittest.mock.patch` 临时替换某个函数,模拟它的行为
|
||||
* **何原理**: Python 的模块和类都是可变的,你可以直接给它们赋值新属性
|
||||
|
||||
### eval/exec
|
||||
* **何用**: 执行字符串形式的 Python 代码
|
||||
* **何处**: `code_py.py` 插件中,用户发送的代码片段会被 `exec()` 执行,实现代码沙箱功能
|
||||
* **何原理**: Python 解释器本身就是一个运行时环境,`eval()` 用于表达式,`exec()` 用于语句
|
||||
|
||||
### 类型提示 (Type Hints)
|
||||
* **何用**: 虽然 Python 是动态类型,但类型提示能让代码更清晰,工具(如 Mypy)也能做静态检查
|
||||
* **何处**: 几乎所有函数和方法的参数、返回值都加了类型提示,这让 Mypyc 编译成为可能
|
||||
* **何原理**: 类型提示只是注解,运行时通常被忽略(除非你用 `typing` 模块做检查)
|
||||
|
||||
357
docs/development-standards.md
Normal file
357
docs/development-standards.md
Normal file
@@ -0,0 +1,357 @@
|
||||
# NEO Bot 开发规范与公约
|
||||
|
||||
写代码很简单,但写出**高性能、不炸裂、好维护**的代码需要遵守规矩。
|
||||
|
||||
本文档定义了 NEO Bot 项目的开发守则、编码公约、注意事项和代码规范。所有贡献者和插件开发者都**必须**遵循这些规范,确保机器人稳定运行、代码质量统一。
|
||||
|
||||
> 如果你觉得规范太麻烦,可以问问镀铬酸钾,他会给你一对一教学。。。但最好还是遵守规矩。
|
||||
|
||||
**补充阅读**:
|
||||
- [插件开发最佳实践](./plugin-development/best-practices.md) - 必读!写插件的基本规矩
|
||||
- [项目结构](./project-structure.md) - 了解代码组织
|
||||
- [核心概念](./core-concepts/architecture.md) - 理解框架设计
|
||||
|
||||
## 1. 开发守则(基本原则)
|
||||
|
||||
### 1.1 异步优先原则
|
||||
- **绝对不要阻塞事件循环**:NeoBot 采用单线程异步架构,任何同步阻塞操作都会导致整个机器人卡死。
|
||||
- **禁止**:`time.sleep()`、同步 `requests`、密集 CPU 计算
|
||||
- **必须**:使用 `await asyncio.sleep()`、异步 HTTP 客户端、线程池执行同步任务
|
||||
|
||||
- **异步任务处理**:长时间运行的任务应使用 `run_in_thread_pool` 或 `asyncio.create_task` 执行,避免阻塞主循环。
|
||||
|
||||
### 1.2 资源管理原则
|
||||
- **连接复用**:禁止重复创建连接和资源实例。
|
||||
- HTTP 请求:使用全局 `aiohttp` session 或插件提供的 `get_session()`
|
||||
- 浏览器操作:必须通过 `browser_manager.get_page()` 获取页面实例
|
||||
- Redis 连接:通过 `redis_manager` 单例访问
|
||||
|
||||
- **资源池化**:浏览器页面、数据库连接等资源必须使用框架提供的池化机制。
|
||||
|
||||
### 1.3 性能优化原则
|
||||
- **缓存策略**:频繁访问的外部数据必须添加缓存。
|
||||
- 短期缓存(<1小时):使用 Redis 或内存缓存
|
||||
- 长期缓存:考虑持久化存储
|
||||
|
||||
- **懒加载**:大型资源或初始化成本高的组件应延迟加载。
|
||||
|
||||
### 1.4 错误处理原则
|
||||
- **异常捕获**:所有插件代码都应妥善处理异常,避免插件崩溃影响机器人运行。
|
||||
- **友好提示**:向用户返回清晰、友好的错误信息,避免暴露内部细节。
|
||||
- **日志记录**:所有重要操作和错误都应记录日志,使用 `ModuleLogger` 进行结构化日志记录。
|
||||
|
||||
### 1.5 安全性原则
|
||||
- **输入验证**:所有用户输入都必须验证和清理,防止注入攻击。
|
||||
- **代码执行安全**:使用沙箱环境执行用户代码,隔离系统资源。
|
||||
- **权限控制**:严格遵循权限管理系统,禁止越权操作。
|
||||
|
||||
### 1.6 跨平台兼容性原则
|
||||
NEO Bot 需要在 **Windows 开发环境**和 **Linux 生产环境**中都能正常运行。
|
||||
|
||||
- **路径处理**:
|
||||
- 使用 `pathlib.Path` 处理文件路径,避免手动拼接字符串。
|
||||
- 使用 `/` 作为路径分隔符(Python 会自动转换)。
|
||||
- 禁止使用硬编码的路径分隔符(如 `\\` 或 `/`)。
|
||||
|
||||
- **系统依赖**:
|
||||
- 避免使用平台特定的系统调用。
|
||||
- 如果必须使用,通过 `sys.platform` 检测平台并提供备选方案。
|
||||
|
||||
- **环境变量**:
|
||||
- 通过 `global_config` 获取配置,而不是直接读取环境变量。
|
||||
- 敏感信息(如 API 密钥)必须通过配置管理。
|
||||
|
||||
- **文件权限**:
|
||||
- 在 Linux 上注意文件权限设置,确保 Bot 有读写权限。
|
||||
- 临时文件应放在系统临时目录(`tempfile.gettempdir()`)。
|
||||
|
||||
## 2. 公约(编码约定)
|
||||
|
||||
### 2.1 项目结构公约
|
||||
- **插件位置**:所有插件必须放置在 `plugins/` 目录下,单个 `.py` 文件或包含 `__init__.py` 的目录。
|
||||
- **模块导入**:遵循标准导入顺序:标准库 → 第三方库 → 本地模块。
|
||||
- **配置访问**:通过 `global_config` 单例访问配置,禁止硬编码配置值。
|
||||
|
||||
### 2.2 单例管理器使用公约
|
||||
NEO Bot 的核心是**单例管理器**(`core/managers/` 目录下的类)。所有全局资源都必须通过管理器访问。
|
||||
|
||||
- **禁止重复创建**:严禁自己实例化管理器类,必须通过导入的单例对象访问。
|
||||
- ✅ `from core.managers.redis_manager import redis_manager`
|
||||
- ❌ `RedisManager()` (错误!会创建新实例)
|
||||
|
||||
- **资源池化**:浏览器页面、数据库连接等资源必须使用管理器提供的池化接口。
|
||||
- ✅ `await browser_manager.get_page()`
|
||||
- ❌ `playwright.chromium.launch()` (错误!会创建新浏览器进程)
|
||||
|
||||
- **数据一致性**:单例管理器确保全局数据一致性,不要绕过管理器直接操作底层资源。
|
||||
|
||||
### 2.2.1 单例模式实现机制
|
||||
|
||||
NEO Bot 提供了两种单例模式实现方式,位于 `core/utils/singleton.py`:
|
||||
|
||||
#### 1. Singleton 基类(继承方式)
|
||||
```python
|
||||
from core.utils.singleton import Singleton
|
||||
|
||||
class MyManager(Singleton):
|
||||
"""通过继承 Singleton 基类实现单例"""
|
||||
|
||||
def __init__(self, config: dict):
|
||||
"""
|
||||
初始化管理器
|
||||
|
||||
Args:
|
||||
config: 配置字典
|
||||
"""
|
||||
# 调用父类 __init__ 确保单例初始化
|
||||
super().__init__()
|
||||
|
||||
# 检查是否已经初始化(防止 __init__ 被多次调用)
|
||||
if hasattr(self, '_my_initialized') and self._my_initialized:
|
||||
return
|
||||
|
||||
# 执行一次性初始化逻辑
|
||||
self.config = config
|
||||
self.resource = None
|
||||
self._initialize_resource()
|
||||
|
||||
# 标记为已初始化
|
||||
self._my_initialized = True
|
||||
|
||||
def _initialize_resource(self):
|
||||
"""初始化资源(只执行一次)"""
|
||||
self.resource = initialize_resource(self.config)
|
||||
|
||||
async def cleanup(self):
|
||||
"""清理资源(单例管理器应实现清理方法)"""
|
||||
if self.resource:
|
||||
await self.resource.close()
|
||||
```
|
||||
|
||||
**特性**:
|
||||
- 通过重写 `__new__` 方法确保每个类只有一个实例
|
||||
- 自动处理重复初始化问题,但建议子类添加额外的初始化检查
|
||||
- 使用全局字典存储实例,避免类型检查问题
|
||||
- 支持带参数的 `__init__` 方法
|
||||
|
||||
#### 2. @singleton 装饰器(装饰器方式)
|
||||
```python
|
||||
from core.utils.singleton import singleton
|
||||
|
||||
@singleton
|
||||
class MyManager:
|
||||
"""通过装饰器实现单例"""
|
||||
|
||||
def __init__(self, config):
|
||||
self.config = config
|
||||
self.resource = None
|
||||
|
||||
async def initialize(self):
|
||||
self.resource = await load_resource()
|
||||
```
|
||||
|
||||
**特性**:
|
||||
- 将普通类转换为单例类,无需修改类继承关系
|
||||
- 保持原始类的元数据(名称、文档字符串等)
|
||||
- 适用于无法修改基类的现有类
|
||||
|
||||
#### 3. 使用建议
|
||||
- **新管理器类**:优先使用 **Singleton 基类继承方式**,结构更清晰
|
||||
- **现有类转换**:使用 **@singleton 装饰器**,无需重构
|
||||
- **线程安全**:两种方式都假设在单线程异步环境中使用,如需线程安全请自行加锁
|
||||
- **导入方式**:单例类应该通过模块级别的实例变量导出,如:
|
||||
```python
|
||||
# redis_manager.py
|
||||
class RedisManager(Singleton):
|
||||
...
|
||||
|
||||
redis_manager = RedisManager() # 创建并导出单例实例
|
||||
```
|
||||
|
||||
#### 4. 重要注意事项
|
||||
- **避免循环导入**:单例类的导入应谨慎处理,避免循环依赖
|
||||
- **初始化时机**:单例在第一次导入时创建,确保所需依赖已就绪
|
||||
- **__init__ 调用语义**:虽然实例是单例,但 `__init__` 方法可能被多次调用(如重新导入时)。应添加额外检查确保一次性逻辑只执行一次。
|
||||
- **资源清理**:单例管理器应在程序退出时清理资源,实现 `cleanup()` 方法
|
||||
|
||||
### 2.3 命名公约
|
||||
- **文件命名**:使用小写字母和下划线,例如 `my_plugin.py`。
|
||||
- **类命名**:使用 `PascalCase`,例如 `CommandManager`。
|
||||
- **函数/方法命名**:使用 `snake_case`,例如 `handle_message`。
|
||||
- **常量命名**:使用 `UPPER_SNAKE_CASE`,例如 `MAX_RETRY_COUNT`。
|
||||
- **变量命名**:使用 `snake_case`,具有描述性,避免单字母变量(循环变量除外)。
|
||||
|
||||
### 2.4 类型提示公约
|
||||
- **全面使用**:所有函数、方法、类属性都应提供类型提示。**这是强制要求**,因为框架开启了 Mypyc 编译。
|
||||
- **性能优化**:类型提示不仅帮助发现 Bug,还能让 Mypyc 生成更高效的机器码。
|
||||
- **返回类型**:明确指定返回类型,包括 `None`。
|
||||
- **复杂类型**:使用 `typing` 模块中的泛型,如 `List[str]`、`Dict[str, Any]`。
|
||||
- **可选参数**:使用 `Optional[...]` 或默认值 `= None`。
|
||||
|
||||
**示例**:
|
||||
```python
|
||||
# 好的写法
|
||||
async def handle(event: MessageEvent, args: list[str]) -> None:
|
||||
...
|
||||
|
||||
# 不好写法(会导致编译警告)
|
||||
async def handle(event, args):
|
||||
...
|
||||
```
|
||||
|
||||
### 2.5 异常处理公约
|
||||
- **自定义异常**:使用框架提供的自定义异常类,避免抛出通用的 `Exception`。
|
||||
- **异常链**:保留原始异常信息,使用 `raise CustomError(...) from e`。
|
||||
- **资源清理**:使用 `try...finally` 或上下文管理器确保资源释放。
|
||||
|
||||
### 2.6 日志记录公约
|
||||
- **模块化日志**:每个模块使用 `ModuleLogger("ModuleName")` 创建专用日志记录器。
|
||||
- **日志级别**:
|
||||
- `DEBUG`:调试信息,详细操作记录
|
||||
- `INFO`:常规操作记录
|
||||
- `WARNING`:预期内的异常或潜在问题
|
||||
- `ERROR`:操作失败但可恢复的错误
|
||||
- `CRITICAL`:系统级错误,需要立即关注
|
||||
|
||||
## 3. 注意事项(常见陷阱)
|
||||
|
||||
### 3.1 异步编程陷阱
|
||||
- **忘记 await**:异步函数调用必须使用 `await`,否则任务不会执行。
|
||||
- **阻塞循环**:在异步函数中执行同步阻塞操作会冻结整个事件循环。
|
||||
- **任务泄漏**:创建的异步任务必须被妥善管理,避免内存泄漏。
|
||||
|
||||
### 3.2 资源管理陷阱
|
||||
- **连接泄漏**:未关闭的 HTTP 连接、数据库连接会导致资源耗尽。
|
||||
- **文件句柄泄漏**:打开的文件必须显式关闭或使用上下文管理器。
|
||||
- **缓存雪崩**:大量缓存同时过期可能导致系统负载激增。
|
||||
|
||||
### 3.3 性能陷阱
|
||||
- **N+1 查询**:避免在循环中执行数据库或 API 查询,使用批量操作。
|
||||
- **内存泄漏**:大型数据结构长时间驻留内存,应定期清理。
|
||||
- **重复计算**:相同的计算结果应缓存,避免重复计算。
|
||||
|
||||
### 3.4 安全性陷阱
|
||||
- **SQL 注入**:使用参数化查询或 ORM,禁止拼接 SQL 字符串。
|
||||
- **XSS 攻击**:渲染用户输入时必须进行 HTML 转义。
|
||||
- **路径遍历**:用户提供的文件路径必须进行规范化验证。
|
||||
|
||||
## 4. 代码规范(详细指南)
|
||||
|
||||
### 4.1 文档字符串规范(强制要求)
|
||||
|
||||
**所有代码必须包含完整的文档字符串**,这是项目质量保证的基础。缺少文档字符串的代码将在审查中被拒绝。
|
||||
|
||||
- **模块级文档**:每个模块顶部应有文档字符串,描述模块功能和主要接口。
|
||||
- **类级文档**:每个类应有文档字符串,描述类的职责、使用方法和示例。
|
||||
- **函数/方法级文档**:每个公共函数和方法必须有文档字符串,包含参数说明、返回值和异常信息。
|
||||
|
||||
**参数注释要求**:
|
||||
1. 每个参数都必须有类型提示和简要说明
|
||||
2. 返回值必须明确说明类型和含义
|
||||
3. 可能抛出的异常必须列出
|
||||
4. 复杂的函数应提供使用示例
|
||||
|
||||
**标准格式示例:**
|
||||
```python
|
||||
def process_data(data: List[str], timeout: int = 30) -> Dict[str, Any]:
|
||||
"""
|
||||
处理数据并返回结果。
|
||||
|
||||
Args:
|
||||
data: 待处理的数据列表
|
||||
timeout: 操作超时时间,单位秒
|
||||
|
||||
Returns:
|
||||
处理结果的字典,包含状态和详情
|
||||
|
||||
Raises:
|
||||
TimeoutError: 处理超时时抛出
|
||||
ValueError: 数据格式错误时抛出
|
||||
|
||||
Example:
|
||||
>>> result = process_data(["item1", "item2"])
|
||||
>>> print(result["status"])
|
||||
"""
|
||||
```
|
||||
|
||||
### 4.2 函数设计规范
|
||||
- **单一职责**:每个函数只做一件事,保持功能简洁。
|
||||
- **参数数量**:函数参数不宜过多(建议 ≤5),过多时考虑使用 `dataclass` 或 `TypedDict`。
|
||||
- **默认参数**:避免使用可变对象作为默认参数,使用 `None` 代替。
|
||||
|
||||
### 4.3 类设计规范
|
||||
- **单一职责**:每个类应有明确的单一职责。
|
||||
- **组合优于继承**:优先使用组合而非继承来复用功能。
|
||||
- **属性访问控制**:使用 `@property` 装饰器控制属性访问,隐藏内部实现。
|
||||
|
||||
### 4.4 错误处理规范
|
||||
- **错误码统一**:使用框架定义的 `ErrorCode` 枚举,避免自定义魔法数字。
|
||||
- **错误响应格式**:使用 `exception_to_error_response` 生成统一错误响应。
|
||||
- **用户友好消息**:错误消息应同时包含技术细节(日志)和用户友好提示(界面)。
|
||||
|
||||
### 4.5 测试规范
|
||||
- **测试覆盖率**:核心功能应达到 80% 以上的测试覆盖率。
|
||||
- **异步测试**:使用 `pytest-asyncio` 进行异步测试。
|
||||
- **测试隔离**:测试用例之间应相互独立,避免依赖执行顺序。
|
||||
|
||||
## 5. 提交与协作规范
|
||||
|
||||
### 5.1 Git 提交规范
|
||||
- **提交信息格式**:遵循 Conventional Commits 规范
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
|
||||
<body>
|
||||
|
||||
<footer>
|
||||
```
|
||||
- **type**:feat、fix、docs、style、refactor、test、chore
|
||||
- **scope**:影响的模块或功能区域
|
||||
- **subject**:简洁的描述(50字符以内)
|
||||
- **body**:详细说明(可选)
|
||||
- **footer**:Breaking Changes 或 Issue 引用
|
||||
|
||||
### 5.2 代码审查规范
|
||||
- **审查重点**:功能正确性、代码规范、性能影响、安全性。
|
||||
- **审查态度**:建设性反馈,避免人身攻击。
|
||||
- **审查时效**:24小时内响应审查请求。
|
||||
|
||||
### 5.3 分支管理规范
|
||||
- **主分支**:`main` 分支始终保持可部署状态。
|
||||
- **功能分支**:从 `main` 创建,命名格式 `feature/简短描述`。
|
||||
- **修复分支**:从 `main` 创建,命名格式 `fix/问题描述`。
|
||||
|
||||
### 5.4 发布规范
|
||||
- **版本号**:遵循语义化版本控制(SemVer):`主版本.次版本.修订版本`
|
||||
- **更新日志**:每次发布都应更新 `CHANGELOG.md`。
|
||||
- **向后兼容**:非主版本更新应保持 API 向后兼容。
|
||||
|
||||
## 6. 插件开发特别规范
|
||||
|
||||
### 6.1 插件元数据
|
||||
每个插件必须在文件顶部定义 `__plugin_meta__` 字典:
|
||||
```python
|
||||
__plugin_meta__ = {
|
||||
"name": "插件名称",
|
||||
"description": "插件功能描述",
|
||||
"usage": "使用说明,包括命令格式和示例",
|
||||
"author": "作者名(可选)",
|
||||
"version": "版本号(可选)",
|
||||
}
|
||||
```
|
||||
|
||||
### 6.2 命令注册
|
||||
- **命令前缀**:使用配置中定义的前缀,不要硬编码。
|
||||
- **权限控制**:使用 `Permission` 枚举指定命令权限级别。
|
||||
- **参数解析**:利用框架的自动参数解析功能,避免手动解析。
|
||||
|
||||
### 6.3 插件生命周期
|
||||
- **初始化**:避免在模块级别执行初始化操作,使用函数包装。
|
||||
- **资源清理**:提供清理函数或使用上下文管理器管理资源。
|
||||
- **错误恢复**:插件崩溃后应能优雅恢复,不影响其他插件。
|
||||
|
||||
## 7. 总结
|
||||
|
||||
遵循这些规范将确保 NeoBot 项目保持高质量、高性能和高可维护性。所有贡献者都应阅读并理解这些规范,并在代码审查中互相监督执行。
|
||||
|
||||
**记住:规范不是束缚,而是高效协作的基础。**
|
||||
Reference in New Issue
Block a user