是否需要为 MessageEvent 添加协程设计？

[LamGC]

为消息事件添加对协程的支持有利于通过不同的交互方式向用户提供服务，但是会增加框架的实现复杂度，因此本问题暂留。
目前的计划细节：

• 【尽可能】 实现时只能作为可被支持，而不允许强制支持（就像 Event 模块中，EventObject 和 Cancelable 的关系）
• 【问题】 该功能主要用于等待用户下一个事件（例如搜图功能中，可以先发送**“/搜图”**，随后再发送一张图片），这部分会增加框架的适配难度。

更多细节稍后补充。

[LamGC]

其实我认为协程完全可以内部实现而不交给框架实现，只需要 保证平台，发送源类型 和 Id 相同即可。

[LamGC]

笔记

原设计

提供协程对象给命令处理器，当命令处理器挂起协程时（尝试接收同一用户的下一条消息，这里应该要换个说法），由于消息处理器会直接将消息传递给命令执行器，所以在命令执行器中设置 hook 用于接收同一用户的下一条消息。
但这个设计有个缺陷：

• 如果用户以较快的速度发出下一条消息，就会错过 Hook 的时机。

预想的新设计

原有的基础上，让协程对象一开始就预先Hook消息，在某一命令处理器正在处理该用户的命令时，该用户的其他命令都压入该处理器的协程队列中，如果需要挂起，则可以更快的获得消息，当命令处理器结束处理后，协程内的消息重新进入命令执行器，根据其中的命令消息调用新的命令处理器，并将剩余的非命令消息压入新命令处理器的协程对象中。
需要注意的事情：

• 当用户连续发送命令时，不应将命令消息压入，以防止将命令抛弃；
• 当用户发出新的命令后，可以考虑将命令中断？或者终止向该协程压入消息，而开始执行新的命令；
  • 不过比较担心的是消息乱序接收的问题，Telegram 还好说，QQ 可能不能保证消息的顺序发送；