javamail收件箱不能所有邮件_处理不同类型的收件箱信息

上文介绍了收件箱信息的分类，那么今天就来聊一聊针对每种分类对应的处理方法。

快速诊断

但是在开始之前，有一件事情是必须要先做的，那就是执行分类这个动作本身。也就是说，在开始针对某种类型的消息进行处理之前，首先要判断一则消息属于哪种类型，我把这个动作称为“快速诊断”。

除了无用的消息之外，另外三种类型的消息应该都不难辨识。对于无用的消息，我觉得关键在于否定自己内心的声音：要不先留着吧，说不定以后还有用呢。在一开始也可以采用“宁可错杀一千，不可放过一个”的原则，尽可能多的把信息归类为无用的消息。害怕会错过重要的消息吗？不用害怕。因为一则消息如果真的很重要，那么它一定会找到一种方式让我知道。

所谓快速，并不是说要用很快的速度把消息阅读完并作出诊断。消息还是要仔细阅读并充分理解的，它该花费多少时间，就应该花费多少时间。这里的快速指的是在诊断时要专注于诊断这件事情本身，特别是在诊断即时聊天工具的收件箱的时候。比如，我自己在诊断工作场合的即时聊天工具里的对话列表时，还没有阅读完旧的消息，新的消息又开始涌入。如果这时候我不能保持专注，很有可能一下子就掉入了收件箱黑洞。等我反应过来的时候，一个小时已经过去了。

无用的信息

如果一则消息是无用的信息，那么在收件箱允许的情况下，我会选择删除这条消息，配合上后续介绍的其他处理方法，可以达到Inbox Zero的状态。除了删除之外，有时候我还会更进一步，比如直接删除某个联系人，取消对某个公众号的关注或者取消订阅一份新闻通讯稿。

当然，并不是所有的收件箱都支持删除消息的，特别是在即时聊天工具的群聊场景里。这时候，我觉得能做的就是尽量少加入群聊或者定期退出群聊来达到“删除”无用信息的效果。

需要稍后阅读的信息

对于需要稍后阅读的信息，我的处理方法是把它们放入到稍后阅读列表中。这里的稍后阅读列表，既可以是稍后阅读在线服务，比如Instapaper或Pocket，也可以是Safari自带的阅读列表，还可以是任务管理软件。总之，只要能使用一个工具来搜集相应的信息以供后续阅读即可。

至于这个稍后阅读的列表是不是会越来越大，大到连打开的欲望都没有了呢？以我个人的经验来说，这实在是太经常发生了。解决之法其实和上文提到的诊断无用信息的方式类似：如无必要，勿增实体。先把会放到稍后阅读列表的信息减少再减少，直到哪天发现可阅读的内容已经不够了，再逐步增加回来。

需要行动的信息

有两种方法来处理需要行动的消息。如果行动可以在两分钟内完成，那么可以遵循GTD的两分钟原则，马上把相应的行动完成。除此之外的所有信息，我都会发送到任务管理软件中进行安排。

近年来很多电子邮件客户端都推出了Reply Later功能。本质上这就是在电子邮件客户端内部提供一个小型的任务管理系统，让使用者可以方便的处理需要回复的消息（回复邮件是行动的一种具体形式）。我觉得这是对收件箱管理的一种很好的探索。但是就我个人而言，我喜欢在一个工具里管理我的所有任务，所以我还是选择把信息发送到软务管理软件中。

需要引用的信息

最后，关于需要引用的信息，那处理的方法自然是进行归档后妥善存放了。很多收件箱都提供一些形似归档的功能，比如置顶，点赞或收藏等等。但是我还是推荐使用专门的归档工具。

比如一封邮件的附件里有一份电子发票，我当然可以选择把这封邮件放到邮箱中的“归档”文件夹，后续再使用电子邮件客户端的搜索功能来查找这封邮件。先不说电子邮箱的运营商可能在某天就销声匿迹了，电子邮件客户端本身的访问也可能存在诸多限制，比如一定需要网络才能访问或者搜索功能不够灵活等等。因此，我认为选择一款专门的归档工具来存放这类信息是更好的选择。

以上就是针对每种类型的信息的处理方法。完成了这些处理，很多时候并没有完成事情本身。比如需要稍后阅读的文章并没有阅读，或者需要完成的行动并没有完成等等。但是这里遵循的原则是：收件箱只是一个收取信息的容器。虽然它是生产力并不可少的部分，但是它并不是生产力本身。我们应该把收件箱和其他生产力活动区别开来，在某个时间段内只专注的做其中一件事情。