阿里的AntDesign在前一阵升级时，在右上角的消息中进行了细分，细分为通知、消息和待办。
在我们具体的实践过程中，各个业务系统对通知、消息和待办的理解，大家一直存在歧义。今天结合我们这一段时间的梳理，进行一个阐述。
1. 首先是待办。
其实是待办消息，这个比较好理解，主要是跟流程相关的消息提醒，比如我有一条待办任务需要处理，或者我有一条别人发过来的催办。在实际的业务系统应用过程中，可以简单的理解成工作流引擎中产生的消息都可以认为是待办。
这种待办消息尤其是在一些OA相关的系统中应用非常普遍。
从交互的角度来讲，该类消息要支持点击跳转到对应的待办消息处理页面。
总结一下特点：
1、 跟工作流有关系
2、 跟某个特定的用户和特定的流程有关系。
3、 出现待办以后，要有处理按钮，支持跳转到的具体的处理页面。
2、 第二个是通知
通知和消息其实很难区分，某种意义上来讲，通知是一个特定的消息。因此在我们的实际规划中，我们讲通知定义为跟用户无关的消息。
在数据库设计的时候，我们讲通知信息表，定义成跟用户无关。怎么理解呢？
比如，我要发一个系统升级公告，只要用户登录系统，就能看到该公告。公告的发布和维护时，不用指定特定的发布人员，默认是群发。
有点类似于消息引擎中的群发消息。
在很多时候，类似于新闻公告之类的。
因此在这种情况下，也不存在用户的已读，未读之类的概念。
这里面有一类特殊的通知，故障通知。我们把这种的故障通知定位通知，比如在物联网的应用场景中，一旦物联网平台发生系统性的故障异常，我们建议把这一类的故障异常作为通知进行发送，保证所有登录运维系统的用户都能看见该类消息。同时，我们将此类故障告警跟钉钉、微信等公告类即时消息进行绑定，保证所有在钉钉群里的用户都能收到消息。而不是发给某个具体的人。
总结一下特点：
1. 具有用户无关性。
2. 可以跟系统进行关联绑定。
3. 可以跟微信公众号、钉钉等进行关联通知。
2、 第二类是消息
其实消息这个概念具有普遍性，大部分场景都可以转换成消息。
为了跟通知和待办进行区分，我们把消息定义为跟用户有关的，需要通知到用户，但是不太需要进行下一步操作的信息。
举例来说，比如用户登录系统完成了某个流程，这种时候，只是告诉相关人员我完成这个动作了，不需要进行额外的操作，这个时候可以发送一个已办的消息。
另外，比如个人密码需要进行定期更新，那需要系统后台自动发送一个消息，告知用户需要进行消息提醒。
再比如，其他用户对你的文章或者发起的流程进行了评论，这种也是一种消息。
总结一下：
1. 消息要跟用户进行绑定，是面向特定用户的消息列表。
2. 消息具有已读未读属性，但是不具备强制阅读属性。
3. 因为具备用户属性，大部分场景下，可以结合短信、邮件、内部消息提醒(APP)等进行特定的推广。
至此，我们对待办、消息、通知进行了分析和梳理，明确了三个概念的区别，你们觉的合适吗？