真正的Windows实际没有“消息映射”的概念，它只有消息发送（Send）、投递（Post）、接收（Get、Peek）与分发（Dispatch）。这些操作的对象都是实实在在的Windows窗口。但是MFC有些不同，因为它用C++的类来封装Windows窗口，这样就必须额外的引入消息在C++类之间“流动”的机制，这被MFC称为消息映射（map，即将Windows消息映射给一个MFC类来处理）与消息流动（route，消息在C++类之间的流动）。
举个例子来说，在Windows中，一个消息发送到了窗口，只有几条路可选：1。自己“吃掉”；2。重新交给父窗口处理；3。交给DefWindowProc处理。在MFC中，如果一个类“接收”到了消息，它的路就比较多了：1。自己“吃掉”；2。发给父窗口的类处理；3。发给父类（注意与“父窗口的类”的不同）处理，如果父类不处理，继续向上派遣，直至最后无人处理，交给DefWindowProc；4。交给相关类处理（比如，CFrameWnd收到消息，会首先交给CView、CDocment处理）。由于这其中的第4点机制，使得MFC的一些非CWnd派生类（即那些不具有Windows窗口的类），比如CDocment，也有机会处理部分消息，增大了编程的灵活性，但另一方面，这又给消息机制平添了许多复杂的路径，因此MFC决定用消息映射表和几个宏来完成这项“艰巨”的任务。
举个例子来说，在Windows中，一个消息发送到了窗口，只有几条路可选：1。自己“吃掉”；2。重新交给父窗口处理；3。交给DefWindowProc处理。在MFC中，如果一个类“接收”到了消息，它的路就比较多了：1。自己“吃掉”；2。发给父窗口的类处理；3。发给父类（注意与“父窗口的类”的不同）处理，如果父类不处理，继续向上派遣，直至最后无人处理，交给DefWindowProc；4。交给相关类处理（比如，CFrameWnd收到消息，会首先交给CView、CDocment处理）。由于这其中的第4点机制，使得MFC的一些非CWnd派生类（即那些不具有Windows窗口的类），比如CDocment，也有机会处理部分消息，增大了编程的灵活性，但另一方面，这又给消息机制平添了许多复杂的路径，因此MFC决定用消息映射表和几个宏来完成这项“艰巨”的任务。
换句话说，由于MFC本身当初实现的目的导致了其消息路径的复杂化
是这样吧？