能不能早日支持onebot 12

[mjy1113451]

有更多功能

[mantoujun12]

#10283 的评论已经很明确说明了，未来有可能会支持，也有人做出了相对应的平台适配器插件。

目前只有 NapCat 支持，其他框架大部分都明确表示不支持，且极少数人使用。

---

下面我拿AI生成的内容解释一下为什么目前不加入：

OneBot 12 是什么

同一条线上的东西：OneBot 11 是 CQHTTP 的“标准化改名”，OneBot 12 是 botuniverse 想彻底重做的一版协议，结构上分三层：

• OneBot Connect（通信层）：HTTP、HTTP Webhook、正向 WS、反向 WS 四种，数据协议支持 JSON / MsgPack
• 数据协议：事件、动作请求、动作响应，统一 action / params / echo，响应带 status / retcode / data
• 接口定义：元接口、消息、单用户（Private/Direct）、单级群组（Group）、两级群组（Guild-Channel）、文件接口

和 v11 的主要区别：

	OneBot 11	OneBot 12
消息格式	CQ 码字符串	结构化消息段，无 CQ 码
平台定位	事实上绑定 QQ	协议层平台无关，分层抽象
错误处理	各自为政	统一 retcode 分级
能力自描述	无	get_supported_actions、元事件
规范状态	事实标准	至今仍标“候选”（12.onebot.dev 标题就是“OneBot 12 标准（候选）”）

“是不是成本太高，不如 v11”

不是 v11 更好，是 v11 赢了生态。 技术上 v12 设计明显更干净，问题全在落地：

1. 规范本身还没转正。 官网到现在写的是“候选”，改一次规范，适配器就得跟一次。
2. QQ 侧的实现基本还是 v11。 NapCat、LLOneBot、Lagrange.Core 这些主流端目前都讲 OB11。真要支持 v12，用户得先有一个 v12 的实现可以连——鸡生蛋问题，做完了可能没人能接。
3. 对 AstrBot 来说收益被重复覆盖了。 OB12 最大的卖点是“一套协议通吃多平台”，但 AstrBot 自己已经有平台抽象层，而且已经有 Satori 适配器（704 + 489 行）在干同一件事。再上一个 OB12，等于给一个已被自家架构解决的问题再加一条平行路径。

成本这边，也不是“加个协议名”那么轻：

• 现有的 aiocqhttp 适配器约 756 行，且它是把活全甩给 aiocqhttp 库的——OB12 没有这种成熟库，传输层、echo 关联、重连、四种通信方式都得自己写
• 事件映射（message/notice/meta + detail_type）、消息段双向映射、action 封装、retcode 错误映射、文件/语音接口差异
• 加上平台元数据、Dashboard 配置、i18n、文档、回归测试

粗估千行级新适配器 + 长期跟着候选规范维护。CQ 码转消息段这部分 AstrBot 4.x 已经做完了，反而最便宜；贵的是外围那些没人看得见的部分。

所以合理的立场

不是“永不做”，是“现在做性价比很差”：

• 官方主线维持“暂不支持、未来可能”
• 生态的事交给生态：疑问 #10283 里 lingyun14beta 那个 astrbot_plugin_onebot12 插件就是正确解法，有人真需要就先用它，用出问题再反推主线要不要收
• 真要有足够多的人在 v12 实现上跑起来，那时候再做才划算

---

就这样，其次这是开源项目，不要乱使用issue/discussion来催项目维护者/贡献者，现在能用别的方法解决的东西就先用着。等到这个协议真正完善了，那些协议实现端支持了，AstrBot自然就会上了。