老板键为什么会慢一步？事件驱动保护链路怎么设计

有人突然走到工位旁边时，老板键的问题往往不是“藏不住窗口”，而是用户必须先发现情况，再完成一次键盘或鼠标操作。事情来得突然、双手正忙着，或者突然按下一组快捷键反而显得刻意，这条链路就可能赶不上现场。

从程序设计角度看，这不是再增加一个快捷键能解决的问题。真正需要改变的是触发模型：从“等待用户下命令”，改为“提前定义条件，让系统在事件成立时启动动作”。

老板键本质上是一条同步命令

传统老板键的处理路径很短：

用户发现情况
    ↓
判断需要隐藏
    ↓
按下快捷键或操作鼠标
    ↓
程序收到输入事件
    ↓
隐藏指定窗口

程序部分通常并不复杂。注册一个全局热键，收到消息后切换窗口状态即可。

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 时，也考虑了这种情况：除了保留手动触发，还允许用户提前配置设备、手势或离席状态，在条件满足时启动预先选择的保护动作。