有人突然走到工位旁边时，老板键的问题往往不是“藏不住窗口”，而是用户必须先发现情况，再完成一次键盘或鼠标操作。事情来得突然、双手正忙着，或者突然按下一组快捷键反而显得刻意，这条链路就可能赶不上现场。
从程序设计角度看，这不是再增加一个快捷键能解决的问题。真正需要改变的是触发模型：从“等待用户下命令”，改为“提前定义条件，让系统在事件成立时启动动作”。
老板键本质上是一条同步命令
传统老板键的处理路径很短：
用户发现情况
↓
判断需要隐藏
↓
按下快捷键或操作鼠标
↓
程序收到输入事件
↓
隐藏指定窗口
程序部分通常并不复杂。注册一个全局热键，收到消息后切换窗口状态即可。
void OnHotKeyPressed()
{
foreach (var window in configuredWindows)
{
window.Hide();
}
}
这里真正不可控的环节在代码之前：用户是否已经注意到、手是否方便操作、快捷键是否被全屏程序占用，以及这次操作会不会过于明显。换句话说，老板键把“检测现场”和“决定触发”的责任都留给了人。
只要人就在键盘前并且反应时间足够，这种设计简单、直接，也容易理解。但它天然依赖临场操作。
事件驱动保护把触发条件前置
另一种思路是把触发条件提前配置好。程序持续接收设备或传感器状态，把不同来源的信号转换成统一事件，再交给策略判断。
USB / 蓝牙 / 摄像头状态
↓
信号归一化
↓
去重与状态确认
↓
触发策略判断
↓
生成一次保护计划
↓
幂等执行动作
这套结构的重点不是“自动化”三个字，而是把信号、策略和动作拆开。设备回调只描述发生了什么，不应该直接操作窗口；策略层决定这个事件在当前配置下是否有意义；执行层只负责完成已经确定的动作。
一个最小事件对象可以保持得很简单：
public sealed record TriggerSignal(
string Source,
string Kind,
long Sequence,
DateTimeOffset ObservedAt);
USB 拔出、蓝牙断开、手势确认和离席状态都可以转成这种稳定结构。后续模块不需要知道原始回调来自哪个 Windows API，也不必为每种设备复制一套执行代码。
原始信号不能直接等于最终触发
设备状态并不总是干净的。蓝牙可能短暂重连，USB 回调可能重复到达，摄像头也可能只在一帧里给出不稳定结果。若收到一次回调就立即执行，误触发概率会随着信号源增加而上升。
比较稳妥的做法是引入“候选状态”：
原始信号 → 候选事件 → 观察与确认 → 正式事件
│
└→ 后续事实相反：撤销候选
候选事件还需要版本号或序列号。新事实到达后，旧的延时任务必须失效，否则设备已经恢复连接，旧任务仍可能在几秒后继续执行。
async Task ObserveAsync(TriggerSignal signal, CancellationToken token)
{
var version = Interlocked.Increment(ref _stateVersion);
await Task.Delay(observationWindow, token);
if (version != Volatile.Read(ref _stateVersion))
return; // 已有更新的状态，旧候选作废
if (!stateStore.StillMatches(signal))
return;
eventQueue.Enqueue(ConfirmedEvent.From(signal));
}
这里的 observationWindow 不是一个可以到处照搬的魔法数字。不同信号的确认方式不同：有的依赖持续时间，有的依赖连续帧，有的只需要系统提供的确定状态。真正应复用的是“候选可撤销”这条规则。
同一个事件只能形成一次有效执行
事件驱动系统还会碰到重复问题。操作系统可能重复报告状态，多个监听入口也可能观察到同一变化。如果每个回调都创建一轮动作，就可能反复隐藏窗口、重复锁定资源，甚至让后到的任务覆盖先到任务的结果。
因此，正式事件应当有稳定标识，执行器按事件标识做幂等判断：
async Task HandleAsync(ConfirmedEvent current)
{
if (!eventJournal.TryBegin(current.Id))
return; // 已处理或正在处理
var plan = policy.Resolve(current);
foreach (var step in plan.Steps)
{
if (snapshot.IsSatisfied(step))
continue;
await executor.ExecuteAsync(step);
}
eventJournal.Complete(current.Id);
}
snapshot 用来区分“执行前本来就是这个状态”和“本次动作改变了状态”。eventJournal 则防止同一事件被重放。两者分开后，日志和故障排查也更清楚。
触发方式和保护动作应该解耦
快捷键、设备断开或摄像头状态回答的是“什么时候开始”；隐藏窗口、改变会话状态或收口资源回答的是“开始后做什么”。把两者写死在一起，会迅速形成组合爆炸：
蓝牙断开并不等于固定执行某个动作
USB 拔出也不应该拥有一套重复的窗口处理代码
同一种保护计划可以由不同触发方式启动
更合适的接口是让策略层返回计划：
ProtectionPlan Resolve(ConfirmedEvent current)
{
var rule = rules.Match(current.Source, current.Kind);
return rule is null
? ProtectionPlan.Empty
: ProtectionPlan.From(rule.SelectedActions);
}
这样增加一种触发来源时，主要工作落在信号适配和状态确认上，不需要重新实现整条动作链。用户调整保护动作时，也不必修改设备监听逻辑。
为什么这个差异在现场很明显
设想几个很普通的情况：同事临时走到工位旁边，用户正拿着文件；会议中突然需要把屏幕转向别人；人已经站起来离开座位，窗口却还保持打开。此时老板键并非没有作用，而是它要求用户仍然处在控制回路里。
事件驱动保护解决的是另一层问题：把“何时触发”提前准备好。设备离开、明确手势或离席状态满足预设条件后，系统再启动已经选择好的动作。它不能预知所有突发情况，设备和摄像头信号也需要提前测试，但至少不再把全部压力留到最后一秒。
我们在开发超级看门狗 SuperWatchDog 时，也考虑了这种情况：除了保留手动触发，还允许用户提前配置设备、手势或离席状态，在条件满足时启动预先选择的保护动作。关于两种思路最核心的差异，可以继续看这篇老板键与预设触发对比。
