Win32系统：窗口隐藏时焦点重分配的触发差异原因探究

核心原因在于不同应用隐藏窗口时，调用的系统API、传递的窗口状态标记，以及系统对窗口“可聚焦性”的判定逻辑存在差异：

• 窗口隐藏的API实现不同
  WPF设置Visibility=Collapsed时，底层会调用Windows原生API ShowWindow并传入SW_HIDE参数，同时将窗口从系统的可见可聚焦窗口列表中移除，明确告知系统该窗口不再具备接收焦点的能力，因此系统会立即触发焦点重分配流程，寻找下一个可用窗口。
  而Discord、Slack这类应用的“隐藏”并非完全调用SW_HIDE，更多是采用托盘最小化逻辑：可能只是将窗口位置移至屏幕可视区域外，或者修改窗口样式为WS_EX_TOOLWINDOW（工具窗口），甚至仅隐藏窗口的渲染层但保留窗口的系统注册信息。系统会认为这类窗口只是暂时不可见，但仍属于可聚焦的活跃窗口，因此不会触发焦点转移。

• 窗口活跃状态的通知逻辑不同
  WPF的Collapsed状态会主动将窗口的IsActive属性设为false，并向系统发送WM_ACTIVATE消息（携带WA_INACTIVE参数），明确告知系统该窗口已失去活跃状态。系统收到这个消息后，会启动焦点重分配机制。
  Discord、Slack在隐藏窗口时，不会主动发送WM_ACTIVATE的失活消息，甚至会通过进程间通信（比如托盘进程持有窗口的活跃标记）让系统认为窗口仍处于“活跃但不可见”的状态，系统自然不会触发焦点转移。

• 应用的窗口设计目标差异
  WPF的Collapsed是为UI布局场景设计的，目标是让窗口/控件彻底脱离交互流程，不再参与任何UI事件和焦点竞争，因此会严格遵循系统的焦点管理规则。
  而Discord、Slack作为即时通讯应用，设计上需要支持快速唤起窗口，因此它们的隐藏逻辑是“后台保留窗口实例，仅隐藏界面”，会刻意维持窗口的系统注册状态，确保用户再次唤起时能快速恢复焦点，而非让系统分配新焦点。

内容的提问来源于stack exchange，提问作者L. Berger