有人离开工位时USB 设备可能先被拔出蓝牙耳机随后断开摄像头又在几帧之后确认座位前没人。如果三个监听模块各自直接操作窗口或资源同一个现实动作就可能被程序执行三遍。这类问题并不只存在于隐私工具。门禁、告警、智能家居和桌面自动化都会面对同一种工程挑战多个信号描述的是同一件事但到达时间、可靠程度和数据格式并不相同。比较稳妥的做法不是在每个回调里增加更多if而是把“观察到变化”“确认事件成立”和“执行一次动作”拆成三层。独立回调为什么容易把同一件事做三遍最直接的实现通常长这样voidOnUsbRemoved()ProtectNow();voidOnBluetoothDisconnected()ProtectNow();voidOnAwayConfirmed()ProtectNow();代码很短但三个回调互相不知道对方是否已经启动保护。若动作包含窗口处理、资源锁定和状态提示就容易出现重复弹窗、重复请求、后到任务覆盖先到结果等问题。更麻烦的是原始回调的语义并不等价USB 拔出通常是一次明确的设备变化蓝牙断开可能只是短暂抖动之后又自动恢复摄像头分类结果可能只在单帧出现需要连续确认快捷键则是用户明确发出的即时命令。因此不能只用一个全局布尔值表示“是否触发”。程序需要先把不同来源转换成统一事件再根据来源完成各自的确认。第一步把不同信号归一化原始回调只负责描述事实不直接决定动作。可以先建立一个足够小的统一对象publicsealedrecordTriggerSignal(stringSource,stringKind,stringSubject,longSequence,DateTimeOffsetObservedAt);Source表示信号来自 USB、蓝牙、摄像头还是快捷键Kind表示离开、断开或手动触发Subject用于区分不同设备或检测来源Sequence防止旧消息晚到后重新生效。归一化之后后续模块只处理TriggerSignal不需要知道底层回调来自哪一种系统接口。USB 回调 ──────┐ 蓝牙状态 ──────┤ 摄像头结果 ────┼→ TriggerSignal → 来源确认器 快捷键消息 ────┘第二步每种来源分别确认但输出同一种正式事件统一格式不代表统一确认方法。蓝牙可以使用“候选可撤销”摄像头可以使用连续结果快捷键则可以直接确认。重要的是确认器最后都输出同一种ConfirmedTrigger。asyncTaskConfirmedTrigger?ConfirmAsync(TriggerSignalsignal,CancellationTokentoken){varruleconfirmationRules.For(signal.Source);varversionversions.Advance(signal.Source,signal.Subject);awaitrule.ObserveAsync(signal,token);if(!versions.IsCurrent(signal.Source,signal.Subject,version))returnnull;// 观察期间出现了更新事实if(!rule.StillMatches(signal))returnnull;// 候选已经恢复或被撤销returnConfirmedTrigger.From(signal);}这里不应把确认时间写成所有来源共用的固定数字。可复用的是“旧候选能被新事实撤销”和“只有当前版本才能升级为正式事件”两条规则。第三步用合并器判断是不是同一次现实事件多个正式事件可能来自同一次离开动作。合并器不应该简单丢弃后到事件因为后到事件仍然提供了有价值的触发原因。更合理的做法是第一条事件创建一次执行会话短时间内到达的相关事件只补充原因不再创建第二条动作链。ConfirmedTrigger ↓ 查找当前聚合会话 ├─ 没有 → 创建会话保存首次策略快照 └─ 已有 → 追加触发原因不重置执行计划 ↓ SingleFlight ↓ 只允许一条动作链进入 Running一个概念性聚合器可以这样写ProtectionSessionAccept(ConfirmedTriggertrigger){lock(_gate){if(_activeis{IsOpen:true}currentcurrent.CanMerge(trigger)){current.AddReason(trigger.Source,trigger.Subject);returncurrent;}varplanpolicy.BuildSnapshot(trigger);_activeProtectionSession.Create(trigger,plan);return_active;}}关键点是BuildSnapshot只在会话首次建立时运行。后续即使用户修改设置正在执行的会话也不应该在中途换成另一套动作否则日志、提示和最终结果会互相矛盾。第四步SingleFlight 只解决并发还需要幂等结果单飞控制保证同一时刻只有一条动作链运行但程序崩溃重试、迟到消息或重复请求仍可能再次触发同一步骤。因此每个步骤还应判断目标是否已经满足。asyncTaskRunAsync(ProtectionSessionsession){if(!singleFlight.TryEnter(session.Id))return;try{foreach(varstepinsession.Plan.Steps){if(awaitstate.IsSatisfiedAsync(step)){session.RecordSkipped(step,already satisfied);continue;}varresultawaitexecutor.ExecuteAsync(step);session.Record(step,result);}}finally{singleFlight.Leave(session.Id);}}“已经满足”不应该被记录成失败。例如某个资源在动作开始前已经处于关闭状态再次请求关闭时最合理的结果是幂等成功或跳过而不是制造一条错误告警。第五步单个动作失败不应让整条链失去结果统一动作链常常包含多个相互独立的步骤。若某一步失败就直接抛出异常并丢弃后续结果用户最终只会看到一个笼统失败无法知道哪些部分已经完成。更适合的结果结构是逐项记录publicsealedrecordStepResult(stringStep,StepStatusStatus,string?UserHint);publicsealedrecordPlanResult(IReadOnlyListStepResultSteps){publicboolIsPartialSteps.Any(xx.StatusStepStatus.Failed)Steps.Any(xx.StatusStepStatus.Succeeded);}这样一个窗口动作失败时不必阻止其它独立资源继续处理最终也可以明确区分全部完成、部分完成和未执行。对于可能影响未保存工作的动作则应由用户预先选择并得到清楚提示不能因为前一步失败而自动升级成更激进的动作。一条完整的数据流把上面的步骤放在一起完整流程如下设备 / 输入 / 摄像头原始状态 ↓ 统一 TriggerSignal ↓ 来源专属确认与候选撤销 ↓ ConfirmedTrigger ↓ 聚合原因 固化计划快照 ↓ SingleFlight ↓ 逐项幂等执行并记录结果 ↓ 全部完成 / 部分完成 / 未执行这套设计的价值不在于让代码显得复杂而是把复杂度放到正确的位置监听器只产生事实确认器过滤抖动聚合器解释多个事实是否属于同一次事件执行器只处理已经固化的计划。为什么这和真实使用场景有关有人离开座位时设备信号不会排队等程序处理。USB、蓝牙、键鼠状态或摄像头结果可能先后到达也可能短暂恢复。如果每个入口都有一套独立动作功能越多重复和冲突反而越明显。我们在开发超级看门狗 SuperWatchDog 时需要同时考虑手动立即保护、快捷键、USB 拔出、蓝牙状态以及可选的手势和离席信号。这些入口的目的不是各自拥有一套“隐藏功能”而是在用户提前选好保护方案后从不同条件启动同一套保护思路尽量同时照顾屏幕、指定窗口和本地私密文件。它仍然需要用户先根据自己的环境测试触发条件也不能替代保存工作、锁定会话等日常习惯。但从工程角度看把多源回调收敛成一次可解释、可去重、可逐项记录的执行比在每个回调里直接调用ProtectNow()更容易维护也更符合突发场景的真实节奏。
