背景

Milky 源自协议端开发者对 OneBot 11 协议 长期以来的强烈不满，具体可以总结为以下方面：

• 设计理念老旧：
  • message_id：OneBot 11 强制规定 message_id 为 32 位整数，可能会出现重复的 ID，并且必须依赖数据库或缓存来建立 message_id 到 NTQQ 内部所用的消息标识符的映射关系。
  • 资源类消息段：OneBot 11 要求协议端在收到消息时直接提供资源类消息段的 URL，这在 NTQQ 中会导致收到的消息无法持久化，因为 URL 可能会失效。
• 类型定义模棱两可：
  • number：OneBot 11 在部分位置没有对本该是数字类型的字段进行严格限制，导致协议端需要进行额外的类型检查和转换。
  • boolean：OneBot 11 的布尔值存在 true false 0 1 "true" "false" "0" "1" "yes" "no" 多达 10 种表示方式，给协议端的解析带来了极大的困扰。
• CQ 码：原本是 CQHTTP 用于序列化消息的格式，但是在具体实现中存在诸多不便之处以及漏洞，并且有时这种格式被滥用，影响了协议端代码的维护难度。此外，CQ 码不支持嵌套，无法完全表达复杂的消息结构。
• 无法覆盖 NTQQ 特性：截至成稿，OneBot 11 的最后一个 commit  停留在 2022 年 8 月 12 日，并没有覆盖“小灰条”戳一戳、群表情回应等新特性。
• 发达而混乱的生态：OneBot 11 至今已有 5 个年头，虽然产生了丰富的协议端和应用端实现，但也造成了大量的分歧，无论是协议端还是应用端的开发者都需要花费大量精力来适配不同的实现。这一点在戳一戳、表情回应等新特性上尤为明显。

Milky 对 OneBot 11 的设计理念进行了全面的反思和改进，具体体现在以下几个方面：

• 全面兼容：Milky 旨在覆盖绝大多数 QQ 特性，适配多种应用场景。
• 简单易用：Milky 力求对协议端和应用端实现均友好，去除不必要的复杂性。
• 清晰规范：Milky 拒绝模棱两可的类型定义，始终保证接口 100% 强类型。