如果你留心观察的话，你会发现这样一个事实：大部分的软件的用户体验中，一般都是在鼠标按键释放后，才会执行相应的动作，而不是按下的时候。例如，当我们按下开始菜单的时候，不会有任何动作发生，只有当我们释放开始菜单的时候，才会弹出开始菜单。(可能有一些例外的情况，例如在文本编辑器里打字就没有遵循这个原则)

为什么大部分的软件都在操作释放的时候才会执行动作呢？

首先，等待鼠标操作完成(按键释放)意味着你为用户创造了取消它的机会。例如，如果在按钮（单选按钮、按钮或复选框）上单击鼠标，然后将鼠标拖离控件，则单击将被取消。但等待按键释放的一个更重要的原因是确保按下的动作不会与操作本身混淆。

例如，假设你处于用户单击对象时对象消失的操作模式。例如，它可能是一个自定义对话框，包含两列，一列显示可用对象，另一列显示正在使用的对象。单击可用对象会将其移动到正在使用的对象列表中，反之亦然。

现在，假设你根据点击而不是鼠标的释放执行操作。当鼠标悬停在某个项目上时，鼠标按钮按下时，将其从列表中删除，并将其添加到相反的列表中。这将移动用户单击的项目，因此鼠标下方的项目现在是移动到原始项目位置的其他项目。然后松开鼠标按钮，你会收到新项目的 WM_LBUTTONUP 消息。

现在有两个问题：首先，用户单击的项目获得了 WM_LBUTTONDOWN 消息，但没有相应的 WM_LBUTTONUP，其次，新项目获得了没有相应 WM_LBUTTONDOWN 的 WM_LBUTTONUP 消息。

你也可以使用键盘遇到类似的情况，尽管这需要更多的工作。例如，如果在按住 Alt 键而不是等待释放时显示对话框，则 Alt 键可能会自动重复并最终传递到该对话框。这样可以防止对话框出现，因为它停滞在由 Alt 键启动的菜单模式中，并且它正在等待你完成菜单操作，然后才会显示自己。

现在，这种类型的不匹配情况通常不是问题，但是当它确实导致问题时，它通常是一个非常令人讨厌的问题。如果你使用某种尝试将鼠标和键盘事件与相应的无窗口对象相关联的无窗口框架，则尤其如此。当操作体验不同步时，事情会变得非常混乱。

总结

我十分赞同本文的观点。
执行的操作必须等待鼠标释放后才会开始，始终给用户取消操作的机会，且尽可能将取消的机会推迟到最后。
这样也可以防止用户的误操作。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《Why do user interface actions tend to occur on the release, not on the press?》