Adapter: WeChatClaw

[Decrabbityyy]

适配器名称

WeChatClaw

适配器描述

通过 微信ClawBot 连接微信

PyPI 项目名

nonebot-adapter-wechatclaw

适配器 import 包名

nonebot.adapters.wechatclaw

适配器项目仓库/主页链接

https://github.com/Decrabbityyy/adapter-wechatclaw

标签

[{"label":"微信","color":"#ea5252"}]

[noneflow]

📃 商店发布检查结果

Adapter: WeChatClaw

✅ 所有测试通过，一切准备就绪！

详情

✅ 项目 主页 返回状态码 200。
✅ 项目 nonebot-adapter-wechatclaw 已发布至 PyPI。
✅ 标签: 微信-#ea5252。
✅ 版本号: 0.1.0。
✅ 发布时间：2026-03-25 20:14:51 CST。

历史测试

✅ 2026-03-26 17:16:38 CST
✅ 2026-03-25 20:28:55 CST
✅ 2026-03-25 20:18:29 CST

---

💡 如需修改信息，请直接修改 issue，机器人会自动更新检查结果。
💡 当插件加载测试失败时，请发布新版本后勾选插件测试勾选框重新运行插件测试。

♻️ 评论已更新至最新检查结果

💪 Powered by NoneFlow

[shoucandanghehe]

Tip

以下 review 来自 copilot opus 4.6

Code Review: Decrabbityyy/adapter-wechatclaw

总体评价：中上水平（7/10）。代码结构清晰、模块划分合理，基本遵循了 NoneBot2 适配器的开发规范。但与官方维护的适配器（如 nonebot/adapter-onebot）相比，仍有一些差距需要弥补。

---

✅ 做得好的地方

1. 项目结构规范 ✔️

包路径 nonebot/adapters/wechatclaw/ 完全遵循 NoneBot2 适配器的命名空间约定，模块划分与官方一致：

文件	用途	是否符合规范
__init__.py	导出核心类	✅
adapter.py	适配器主逻辑	✅
bot.py	Bot 实现	✅
event.py	事件模型	✅
message.py	消息段定义	✅
model.py	协议数据模型	✅
config.py	配置模型	✅
exception.py	异常类	✅
log.py	日志工具	✅

2. 核心类实现正确

• Adapter 继承 BaseAdapter，正确使用 @override 装饰器
• Bot 继承 BaseBot，实现了 send() 方法
• Event 继承 BaseEvent，实现了所有抽象方法
• Message/MessageSegment 继承基类，实现了 _construct、get_segment_class 等
• 异常类正确继承了 AdapterException 体系

3. 工程化细节不错

• pyproject.toml 配置了 ruff、pyright、isort 等工具，lint 规则全面
• 使用 from __future__ import annotations 延迟类型求值
• TYPE_CHECKING 守卫，避免循环导入
• logger_wrapper 日志包装与官方用法一致
• 多账号支持（wechatclaw_accounts）设计合理
• CDN 媒体上传/下载、AES 加解密实现完整

4. 连接管理模式与官方一致

# adapter.py — 与 adapter-onebot 的 _setup/_start_forward/_stop 模式高度相似
def _setup(self) -> None:
    self.driver.on_startup(self._start_polling)
    self.driver.on_shutdown(self._stop)

---

⚠️ 需要改进的问题

1. 🔴 _call_api 未实现（关键缺陷）

在 NoneBot2 中，Bot.call_api() 最终会调用 Adapter._call_api()。但 adapter.py 中的 Adapter 类 没有 @override 实现 _call_api() 方法。

对比官方 adapter-onebot 的做法：

# 官方做法：Adapter 类中必须重写 _call_api
@override
async def _call_api(self, bot: Bot, api: str, **data: Any) -> Any:
    ...

当前代码中 bot.py 的 send_text_message 等方法通过 self.call_api("send_message", ...) 调用，但适配器侧没有对应的 _call_api 分发逻辑。这会导致 call_api 调用时直接报错或走到基类的空实现。

建议：在 Adapter 中实现 _call_api() 方法，根据 api 字符串分发到 _send_message_api、_send_typing_api、_get_config_api 等内部方法。

2. 🔴 adapter.py 被截断 / _parse_message 可能过长

adapter.py 有 24KB，_parse_message、发送消息的 _call_api 分发等核心方法应在其中，文件过大。官方适配器会把 API 调用分到单独模块中。

建议：考虑把消息解析逻辑拆分为独立的 parser.py，API 调用拆分为 api.py。

3. 🟡 Event.get_type() 基类返回空字符串

    @override
    def get_type(self) -> str:
        return ""

NoneBot2 的事件分发依赖 get_type() 返回 "message" / "notice" / "request" / "meta_event" 等标准类型。基类 Event 返回空字符串可能导致无法被正确匹配。

建议：改为返回 "meta_event" 或抛出 NotImplementedError，强制子类覆盖。

4. 🟡 枚举类使用常量类而非 IntEnum

class UploadMediaType:
    IMAGE = 1
    VIDEO = 2
    ...
class MessageType:
    NONE = 0
    USER = 1
    BOT = 2

Python 有 enum.IntEnum，使用它可以获得更好的类型安全性、序列化/反序列化支持和调试输出。

建议：改用 IntEnum：

from enum import IntEnum
class UploadMediaType(IntEnum):
    IMAGE = 1
    VIDEO = 2
    ...

5. 🟡 Bot.send() 只发送第一个媒体段

        if media_segs:
            seg = media_segs[0]  # 只取了第一个！

当消息中包含多个媒体段（如多张图片）时，只会发送第一个，其余被静默忽略。

建议：遍历所有 media_segs 逐个发送，或至少在日志中警告用户。

6. 🟡 _context_tokens 可能内存泄漏

        self._context_tokens: dict[str, str] = {}

每个不同的 user_id 都会往字典里加一条，没有淘汰机制。长时间运行后可能积累大量条目。

建议：使用 collections.OrderedDict 或 functools.lru_cache，设置上限并自动淘汰旧条目。

7. 🟡 media.py / utils.py 中的错误类型不统一

utils.py 和 media.py 中抛出的是 RuntimeError，而非适配器自定义的 NetworkError。异常体系不统一。

建议：CDN 相关网络操作统一使用 NetworkError，文件校验等用 ValueError，API 错误用 ActionFailed。

8. 🟡 __init__.py 缺少 __all__ 导出

from .bot import Bot as Bot
from .event import Event as Event
from .event import MessageEvent as MessageEvent
from .adapter import Adapter as Adapter
from .message import Message as Message
from .message import MessageSegment as MessageSegment

官方适配器通常定义 __all__ 列表来明确公开 API。虽然使用 as 别名的写法（PEP 484 re-export）也是可行的，但缺少了一些应该导出的类型如 Config、各种具体事件子类 (TextMessageEvent 等)、异常类。

9. 🟢 缺少测试和 CI

官方适配器（如 adapter-onebot）有完整的 tests/ 目录和 GitHub Actions CI/CD。此仓库没有任何测试代码和 CI 配置。

10. 🟢 缺少 py.typed 标记文件

PEP 561 要求在包中放置 py.typed 文件来声明包支持类型检查。官方适配器都有此文件。

11. 🟢 README 文档过于简略

官方适配器有详细的 README、badge、配置说明、事件列表。此项目的 README 只有最基础的登录和 Driver 说明。

---

📊 与官方 adapter-onebot 的对比总结

维度	adapter-onebot	adapter-wechatclaw	评价
包结构	nonebot/adapters/onebot/v11/	nonebot/adapters/wechatclaw/	✅ 一致
_call_api 实现	✅ 完整实现	❌ 缺失	🔴 关键缺陷
_setup 模式	✅ startup/shutdown	✅ startup/shutdown	✅ 一致
Event 类型系统	丰富的 Collator 匹配	简单子类继承	🟡 可接受但不够灵活
配置管理	get_plugin_config	get_plugin_config	✅ 一致
异常体系	完整	基本完整但使用不统一	🟡
日志	logger_wrapper	logger_wrapper	✅ 一致
类型标注	完善 + py.typed	完善但缺 py.typed	🟡
测试	pytest 完整覆盖	无	🔴
CI/CD	GitHub Actions	无	🔴
文档	详细	简略	🟡

---

🎯 优先修复建议

1. （P0）实现 Adapter._call_api() — 这是适配器能正常工作的关键
2. （P1）修复 Event.get_type() 基类返回空字符串的问题
3. （P1）统一异常类型使用
4. （P2）补充 __all__ 导出和 py.typed 标记
5. （P2）处理多媒体段发送和 _context_tokens 内存泄漏
6. （P3）添加单元测试和 CI
7. （P3）完善 README 文档

总体来说，这个适配器的代码风格和架构理念是正确的，看得出作者参考了官方适配器的写法。核心问题在于 _call_api 的缺失和工程化配套（测试/CI/文档）的不足。修复这些后，将是一个质量不错的第三方适配器。

[zhangshichun]

Mark 希望早日用上：）