Lagrange.OneBot如何实现消息撤回监听？

Question

在使用 Lagrange.OneBot 实现消息撤回监听时，常见问题是：为何已启用 `enable_reverse_ws` 或正确配置了事件上报地址，但仍无法接收到 `notice.group_recall` 或 `notice.friend_recall` 事件？可能原因包括协议版本不匹配、后端未开启完整通知事件推送、客户端未正确订阅相关事件类型，或 OneBot V12 规范支持不完整导致撤回事件被忽略。如何确保 Lagrange.Core 正确解析并转发消息撤回事件至前端应用？

Answer 1

一、基础排查：确认配置与连接状态

在使用 Lagrange.OneBot 实现消息撤回监听时，首要步骤是验证基础通信链路是否正常。即使已启用 enable_reverse_ws 或正确配置了事件上报地址（如正向 HTTP 回调或反向 WebSocket），仍可能因网络隔离、防火墙策略或 URL 路径拼写错误导致事件无法送达。

• 检查 OneBot 服务端日志中是否有客户端连接成功的记录。
• 确认 post_url 或 reverse_wss 地址可被外部访问，并返回 HTTP 200 响应。
• 使用 curl 或 Postman 模拟发送测试事件，验证回调接口是否能接收到任意类型的通知。

二、协议版本兼容性分析

Lagrange.Core 遵循 OneBot 标准进行事件封装，但不同版本对 notice.group_recall 和 notice.friend_recall 的支持存在差异。OneBot V11 并未明确定义撤回事件结构，而 V12 引入了更细粒度的 notice_type: "message_recall" 及子类型区分。

OneBot 版本	是否支持 recall 事件	事件字段示例
V11	部分实现（非标准）	{"notice_type": "group_recall", ...}
V12	标准支持	{"type": "notice", "detail_type": "message_recall", "sub_type": "group"|"private"}

若前端应用基于 V12 规范开发，而后端 Lagrange.OneBot 输出为类 V11 结构，则需中间层做协议映射转换。

三、后端事件推送开关验证

Lagrange.Core 内部通过插件机制控制事件广播行为。即使网络通畅，若核心模块未注册“通知事件生成器”，则撤回操作不会触发任何输出。

// 示例：确保启用了 Notice 事件处理器
services.AddLagrangeService(options =>
{
    options.EnableGroupMessage = true;
    options.EnableFriendMessage = true;
    options.EnableNoticeEvents = true; // 关键开关
});
    

查阅源码中 EventProcessor.cs 是否包含对 RecallPacket 的解析逻辑，并将其映射至 OneBot 标准事件结构。

四、客户端事件订阅机制审查

某些 OneBot 实现采用“按需订阅”模型，即客户端必须显式声明感兴趣的事件类型，否则服务端将过滤对应消息。这常见于 WebSocket 连接初始化阶段的 meta_event.heartbeat 后的 capabilities 声明。

1. 检查客户端是否发送了 subscribe_events 请求。
2. 确认订阅列表中包含 notice 类型及其子项 group_recall 和 friend_recall。
3. 观察服务端是否回应 meta_event.connect 中携带 accepted_events 字段确认订阅成功。

五、Lagrange.Core 源码级调试建议

当上述配置均无误时，问题可能出在协议解析层。QQ 协议中的撤回指令以特定 TLV 数据包形式传输，需正确解码才能触发上层事件。

// 简化版处理流程示意
public void HandleRecallPacket(TlvPacket packet)
{
    var recallInfo = ParseRecallBody(packet.Data);
    if (recallInfo.IsGroup)
    {
        PublishOneBotEvent(new {
            time = UnixTime.Now,
            self_id = BotUin,
            post_type = "notice",
            notice_type = "group_recall",
            group_id = recallInfo.GroupId,
            user_id = recallInfo.OperatorId,
            message_id = recallInfo.MessageId
        });
    }
}
    

六、完整事件流追踪流程图

以下 Mermaid 流程图展示了从 QQ 客户端撤回到前端应用接收的全链路：

graph TD
            A[用户在QQ客户端撤回消息] --> B{Lagrange.Core捕获Recall协议包}
            B --> C[解析TLV数据获取群组/好友ID]
            C --> D[构造OneBot V11/V12兼容事件对象]
            D --> E{启用enable_reverse_ws?}
            E -->|是| F[通过WebSocket推送至前端]
            E -->|否| G[发送HTTP POST到post_url]
            F --> H[前端监听ws.on('notice.group_recall')]
            G --> I[服务器解析JSON并处理撤回逻辑]
            H --> J[业务系统更新UI或执行后续动作]
            I --> J

七、跨平台适配与扩展策略

面对 OneBot V12 规范支持不完整的问题，推荐采用抽象事件总线模式，在 Lagrange.OneBot 与业务系统之间加入适配中间件。该中间件负责：

• 统一事件命名空间，将 group_recall 映射为 notice.message_recall[group]。
• 补充缺失字段如 operator_id、target_message_id 等。
• 提供 Webhook 过滤规则引擎，允许按群组、用户黑白名单动态开启撤回监听。