家里和公司加起来不到十台设备，平时没人守着，NAS 半夜重启、工控机掉线这种事，基本都要等第二天有人喊“连不上了”才发现。之前试过 Zabbix 和 Uptime Kuma，对个人场景来说都偏重，配置页面比监控本身还复杂。后来我用 .NET 9 写了一个极简的设备监控工具，专门解决三件事：上线/离线实时提醒、状态变化即时推送、以及全屏状态下自动静音。
这个工具本质就是一个可以常驻后台的探活程序，每隔几秒去探测目标设备，一旦状态发生翻转就立刻触发通知。它不像传统监控平台那样要求你维护一套数据库、图表和告警规则，配置一个 JSON 文件就能跑。如果你是个人开发者、运维，或者家里有几台自建服务设备，需要第一时间知道它们是否在线，这套方案可以直接参考，代码量也不大，全部核心逻辑加起来不到一千行。
1. 为什么要写这个监控工具：需求场景与分析
先说痛点。我手上的设备分布在两个地方：家里有三台常开机器，一台 NAS 负责存储和跑 Docker 服务，一台下载机兼做家庭媒体中心，还有一台主力游戏工作站；公司那边有几台工控机分别放在不同楼层，它们的任务是采集数据和驱动现场设备。这些机器大多数时候是稳定的，但只要出问题，基本就是“没人发现”，因为不会有人专门盯着它们。
早期我用的是定时任务加远程登录的方式：每隔几个小时手动看一眼。后来设备多了就扛不住了，经常是业务侧反馈“某个设备连不上了”，我再远程登进去排查，等定位到问题时已经过去大半天。也试过部署完整监控平台，但像 Zabbix 这种需要数据库、Agent 采集、告警媒介一堆配置，对十台以内的设备来说完全是杀鸡用牛刀；Uptime Kuma 虽然轻，但它的通知渠道是按照“网站可用性”的思路设计的，对局域网内的设备探活支持不够细，比如我想探测某个 TCP 端口、想在状态抖动时做延迟判定，都得自己改。
所以我的需求其实很具体：能同时监控多个协议的目标设备、状态变化时立刻通过各种通道提醒我、不会因为网络抖动产生轰炸式告警、最好还能在我全屏看电影或做演示时不打断现场。前三点是监控工具的底线，最后一点属于体验优化，但用下来发现它最能提升幸福感。试想你在会议室投屏演示，突然电脑发出尖锐的告警声，全场目光都扫过来，那画面太尴尬了。
基于这些诉求，我决定自己写一个。选 .NET 9 不是因为它最热门，而是这个版本在 AOT 发布、单文件部署和性能上确实有实打实的改进。我可以用一个 Worker Service 模板搭出后台常驻程序，用 C# 的异步特性做并发探测，再通过 P/Invoke 调用 Windows API 实现全屏检测和音量控制。整套方案不依赖第三方框架，部署时就是一个 exe 加一个 JSON 配置，清爽得很。
2. 整体设计思路与技术选型
2.1 功能模块划分
写工具之前我先把功能拆成了四个模块：探活引擎、状态机、通知分发器、全屏静音控制器。探活引擎负责按周期发起探测请求；状态机负责维护每个设备的当前状态和历史记录；通知分发器接收状态变化的信号，以合适的渠道发出去；全屏静音控制器单独跑一个监视循环，检测到前台窗口进入全屏就执行静音操作。
这四个模块之间通过接口解耦，任何一块都可以单独替换。比如探活引擎可以换成 SNMP 采集器，通知分发器可以集成企业微信机器人，全屏检测逻辑也可以扩展成多显示器支持。我当时刻意避免把所有逻辑揉进一个类里，因为这种小工具刚写完会觉得很简单，一旦用上几个月，各种边界条件都来了，模块化至少让我改起来不用牵一发动全身。
整体的运行流程是这样的：程序启动后读取配置文件，把设备列表加载进内存，启动一个后台任务循环；每个设备按各自的探测周期被调度，探测结果交给状态机；状态机内部维护连续成功次数和连续失败次数，只有当连续失败次数超过阈值时才判定为离线，反之才判定为上线；每次状态翻转，通知分发器就把事件推给所有注册的通道，同时全屏静音控制器根据当前是否处于全屏状态决定要不要压低音量。
2.2 为什么选择 .NET 9 而不是其他技术栈
这个项目是对实时性有一定要求的，但单纯用脚本也能写。真正让我锁定 .NET 9 的有三个原因：一是 C# 的异步模型写并发探测很顺手，二是 .NET 9 对 AOT 和 Native AOT 的支持比之前成熟，可以发布成不依赖运行时的小体积单文件，三是 Windows 生态下的系统级调用，比如窗口枚举、音量控制，用 P/Invoke 就能搞定，不用像 Electron 那样包一个浏览器内核。
顺带提一句，.NET 9 在周期任务这块也有了更顺手的工具。System.Threading.PeriodicTimer 在 .NET 6 引入后，到 .NET 9 用起来已经很舒服，比传统 Timer + 回调的方式直观得多，也天然支持异步。我用它做探活循环和全屏检测循环的主时钟，代码写起来非常干净。
性能上，.NET 9 的运行时开销对这个场景来说完全不是问题。我的探活并发度最高也就二十个目标，每次探测都是网络 IO 等待，CPU 占用几乎可以忽略。真正要注意的反而是不要在异步回调里做耗时同步操作，否则容易把线程池拖垮。
2.3 进程形态与部署结构
程序采用 Worker Service 形态，可以以后台服务方式跑，也能用控制台方式前台运行。Windows 上我建议注册成系统服务，配合 .NET 9 的单文件发布，部署流程就是：发布一次，把一个 exe 丢到服务器或某台常开机器上，注册服务，开机自启。
配置方面，我用 appsettings.json 存基础参数，用独立的 devices.json 存设备列表。后者才是用户真正需要经常改的，比如新增一台机器、调整探测端口，不需要重新编译，改完配置重启一下服务就行。早期我把所有东西塞进一个配置文件，后来发现设备列表和程序参数混在一起，每次要小心翼翼地改，拆开后清爽多了。
3. 核心功能实现：设备探活与状态判定
3.1 探活协议的选择：ICMP、TCP 还是 HTTP
不同的设备类型适合不同的探测方式，实际操作中我分成三种场景：纯网络设备用 ICMP Ping，服务型设备用 TCP 端口探测，Web 服务用 HTTP 健康检查。
ICMP Ping 适合判断“这台机器还开着吗”，但它有个明显问题：很多网络环境会过滤 ICMP 包，或者设备本身有防火墙策略，Ping 不通不代表设备离线。而且 ICMP 容易受网络拥堵影响，偶尔丢一两个包会触发误报。TCP 探测则更可靠，它直接尝试和目标 IP 的某个端口建立连接，能连上基本说明设备活着，服务也在监听。HTTP 健康检查更进一步，它不只验证端口通，还验证返回的 HTTP 状态码是否符合预期。
我给每个设备设置三种探测类型，而不是统一用 Ping。比如 NAS 就同时监控它的 SSH 端口和 Web 管理页面，工控机监控它的采集服务端口，普通电脑就 Ping 一下，但阈值调得比较宽松。这么做的好处是误报率大幅下降，代价是配置稍微复杂点，但对单机几十台设备的规模来说完全可控。
3.2 状态机：如何避免状态抖动造成的误报
状态判定是整个工具的骨架，处理不好就会在日志里看到“上线-离线-上线”反复横跳。我的处理方式是引入连续失败次数和连续成功次数的概念。默认配置下，连续 3 次探测失败才判定为离线，连续 2 次成功才判定为上线，每次探测之间间隔 10 秒，也就是说一台设备至少要连续 30 秒不通才会触发离线告警。
这种设计对应的是“抖动抑制”。周期性网络波动很常见，比如 Wi-Fi 弱网环境、交换机瞬时丢包、设备负载高导致响应变慢，这些都会让单次探测超时。如果每次超时都立刻告警，一天下来你的手机要被通知塞满，而且会掩盖真实问题。有了连续失败次数的累积，偶然的超时会被自动忽略，真实掉线则会稳定触发。
状态机的核心数据结构很简单：每个设备维护一个 CurrentState 和两个计数器。CurrentState 只有 Unknown、Up、Down 三种；Unknown 是程序启动时的初始值，第一轮探测成功就进入 Up，失败则进入 Down，这避免了启动时疯狂告警。代码实现上就是下面这个逻辑：探测成功后计数器清空，失败时累加，达到阈值才翻转状态。
public enum DeviceState { Unknown, Up, Down } public class DeviceMonitor { private readonly DeviceConfig _config; private readonly IProbe _probe; private readonly INotifier _notifier; private readonly List<int> _recentResults = new(); public DeviceState State { get; private set; } = DeviceState.Unknown; public DateTime LastChangedAt { get; private set; } public DeviceMonitor(DeviceConfig config, IProbe probe, INotifier notifier) { _config = config; _probe = probe; _notifier = notifier; } public async Task CheckAsync(CancellationToken ct) { bool isUp = await _probe.ProbeAsync(_config, ct); _recentResults.Add(isUp ? 1 : 0); if (_recentResults.Count > _config.MaxAttempts) _recentResults.RemoveAt(0); int successCount = _recentResults.Count(r => r == 1); int failCount = _recentResults.Count(r => r == 0); DeviceState newState = State; if (_config.FailureThreshold > 0 && failCount >= _config.FailureThreshold) newState = DeviceState.Down; else if (_config.SuccessThreshold > 0 && successCount >= _config.SuccessThreshold) newState = DeviceState.Up; if (newState != State) { State = newState; LastChangedAt = DateTime.Now; await _notifier.NotifyAsync(_config.Name, State, ct); } } }注意观察这里的细节：我用了 _recentResults 列表来保存最近几次探测结果，然后统计成功和失败次数。这样即使中间有一次成功，只要失败次数仍然达到阈值，也是算离线的。比单纯累加计数更符合“最近一段时间内持续失败”的语义，也更容易在配置里表达“几次失败算掉线”。
3.3 实时提醒通道：从控制台到手机推送
状态变化之后要做的是通知。刚开始我只在控制台输出日志，但工具的定位是“没人盯着也要知道”，日志根本不够。后来加了文件日志和 Windows 事件日志，发现还是不够，因为人不会一直守在电脑前。真正让我觉得“实时”的是接入了 Webhook 通知，把状态变化直接推到手机。
通知分发器定义了一个 INotifier 接口，所有通知通道都实现这个接口。这样不仅方便扩展，还可以在一次状态变化时同时推送多个通道。我的默认配置同时开着三个通道：控制台输出、Windows Toast 通知、Webhook 推送。控制台和 Toast 适合人在电脑前的时候，Webhook 适合远程盯着手机。
Toast 通知用的是 Windows 的原生通知机制，需要在代码里调用 Windows App SDK 或者传统的 Windows.UI.Notifications。对于一个小工具来说这可能有点重，但我发现从 .NET 9 开始，Windows 系统上的 Toast 集成已经有不少封装库能用，选一个稳定的 NuGet 包就能省掉大量平台代码。Webhook 就简单多了，一个 HttpClient POST 请求，把设备名、状态、时间和详情以 JSON 发出去。我把它接到一个支持自定义 Webhook 的消息聚合服务上，这样手机和电脑都能秒收。
需要特别说明的是，通知发送本身要做异步和重试。比如网络断了的时候，Webhook 可能发不出去，你至少要把它记到日志里，并在网络恢复后补发一条。不过补发方案我没有做太复杂，因为状态发生变化时一般会连续发几条（探活循环还在跑），真实场景下基本不会漏。
4. 核心功能实现：全屏检测与自动静音
4.1 全屏窗口检测：怎么判断用户正在全屏
这段是标题里最吸引人的功能。一开始我也以为全屏检测要调用复杂的图形 API，后来发现 Windows 给了很直接的判断方式：取当前前台窗口，拿它的窗口矩形，和屏幕的虚拟分辨率比较。如果窗口覆盖了整个屏幕区域，就认为处于全屏状态。
关键点有两个：一个是排除桌面和任务栏的干扰，另一个是注意多显示器环境。桌面进程的窗口矩形也是满屏的，但它不能算全屏应用；任务栏通常占据屏幕底部一小块区域，所以如果拿任务栏窗口来做比较，它的矩形肯定小于屏幕。实际代码里，我先获取前台窗口句柄，然后用 GetWindowRect 拿到窗口坐标，再和 GetSystemMetrics 拿到的屏幕宽度和高度比较。
using System.Runtime.InteropServices; public static class FullScreenDetector { [StructLayout(LayoutKind.Sequential)] private struct RECT { public int Left; public int Top; public int Right; public int Bottom; } [DllImport("user32.dll")] private static extern IntPtr GetForegroundWindow(); [DllImport("user32.dll")] private static extern bool GetWindowRect(IntPtr hWnd, out RECT rect); [DllImport("user32.dll")] private static extern IntPtr GetShellWindow(); [DllImport("user32.dll")] private static extern int GetSystemMetrics(int index); private const int SM_CXSCREEN = 0; private const int SM_CYSCREEN = 1; public static bool IsFullScreen() { IntPtr hWnd = GetForegroundWindow(); if (hWnd == IntPtr.Zero) return false; // 排除桌面窗口 if (hWnd == GetShellWindow()) return false; if (!GetWindowRect(hWnd, out RECT rect)) return false; int screenWidth = GetSystemMetrics(SM_CXSCREEN); int screenHeight = GetSystemMetrics(SM_CYSCREEN); // 排除最小化或空窗口 if (rect.Right - rect.Left <= 0 || rect.Bottom - rect.Top <= 0) return false; return rect.Left <= 0 && rect.Top <= 0 && rect.Right >= screenWidth && rect.Bottom >= screenHeight; } }这套逻辑对大多数情况都有效。浏览器按 F11 进入全屏、视频播放器全屏、PowerPoint 演示模式、绝大多数游戏的全屏模式，前台窗口矩形都会覆盖整个屏幕。无边框窗口模式的游戏只要尺寸对齐屏幕边界，同样能被识别。真正的盲区是某些特殊窗口，比如 DirectX 早期版本依赖独占模式时，窗口矩形不一定正确，但现代 Windows 应用基本都是标准窗口，实测下来问题不大。
4.2 系统音量控制：静音与恢复的完整方案
全屏检测只是第一步，真正执行静音得调系统音量接口。我在 Windows 上用的方式是 Core Audio API，通过 NAudio 库封装好的 MMDeviceEnumerator 获取默认音频终结点，然后控制 AudioEndpointVolume 的 Mute 属性。这套接口和 Windows 控制面板里“静音”按钮操作的是同一个底层开关，所以不是偷偷把某个播放器关掉，而是真的把系统输出音量静音了。
using NAudio.CoreAudioApi; public class AudioMuter { private MMDevice _device; public void Initialize() { var enumerator = new MMDeviceEnumerator(); _device = enumerator.GetDefaultAudioEndpoint(DataFlow.Render, Role.Multimedia); } public void SetMute(bool mute) { if (_device == null) return; _device.AudioEndpointVolume.Mute = mute; } public bool IsMuted() { return _device?.AudioEndpointVolume.Mute ?? false; } }这里有个容易踩的坑：默认音频终结点可能在使用过程中切换。比如你用 HDMI 接显示器听音量，后来拔掉插了耳机，默认端点就变了。所以静音控制器不能只在启动时初始化一次设备对象，得在状态变化时重新检查当前默认端点，否则可能出现“我以为静音了，但声音从新设备传出来”的情况。
另一个坑是恢复音量的时机。我最初是检测到全屏退出就立刻解除静音，但有些应用在退出全屏时也会主动改音量状态，造成冲突。后来我把恢复逻辑做成带延迟的：退出全屏后等待 500 毫秒，再检查音量状态并恢复。如果期间又进入全屏，就取消恢复操作。这样既不会误恢复，也不会反复切换。
4.3 边界情况：多显示器、锁屏、屏保
全屏检测在单显示器下很好用，多显示器环境就要小心。我的工具默认只检测主显示器，因为大多数全屏应用行为不确定：有些游戏在副屏全屏播放，窗户矩形实际落在副屏坐标上，但如果用主屏尺寸比较会误判。更稳妥的做法是拿 GetSystemMetrics 的虚拟屏幕范围来做判断，但虚拟屏幕包含所有显示器的总边界，这样副屏全屏也能识别。
我还有意加了一个排除条件：如果前台窗口属于系统级的锁屏界面或屏幕保护程序，不做静音处理。因为用户离开电脑后屏幕会自动锁，前台窗口可能变成锁屏进程，这时候去静音没有意义，反而可能在用户回来解锁后产生迷惑。实现方式是把已知的系统关键进程名放到一个排除列表里，检测到就跳过。
另外要提一下全屏静音和普通静音的关系。我的工具只在“全屏事件发生”时临时静音，退出全屏后恢复。如果用户本来就把系统音量手动设为静音，工具不应该自动解开它。所以代码里我会记录进入全屏前的静音状态，退出时只恢复到这个原始状态，而不是无脑取消静音。这个细节很重要，否则会出现“看个电影被静音，退出全屏后电脑突然出声”的尴尬。
5. 项目配置、关键代码与部署实战
5.1 项目结构与配置格式
项目骨架基于 dotnet new worker，主程序是一个 Worker 类，里面注入了探活引擎、状态管理器和通知分发器。配置文件拆成了两个：appsettings.json 放全局参数，devices.json 放设备列表。全局参数包括探测间隔、静音相关开关、通知开关和日志级别；设备列表里每个设备有名称、探测类型、目标地址、端口、阈值等。
一个典型的 devices.json 长这样：
[ { "name": "主NAS", "probeType": "tcp", "host": "192.168.1.10", "port": 22, "intervalSeconds": 10, "failureThreshold": 3, "successThreshold": 2 }, { "name": "公司工控机A", "probeType": "http", "url": "http://192.168.20.45:8080/health", "expectedStatusCode": 200, "intervalSeconds": 15, "failureThreshold": 3, "successThreshold": 2 }, { "name": "下载机", "probeType": "icmp", "host": "192.168.1.20", "intervalSeconds": 10, "failureThreshold": 5, "successThreshold": 2 } ]这个格式可以交给不懂代码的人改，只要说明清楚每个字段含义就行。对普通用户来说，最常改的是 host、port 和两个阈值。FailureThreshold 越大越不容易误报，但探测到真实掉线的时间也越长；SuccessThreshold 保持 2 到 3 即可，因为上线恢复不应该拖太久。
5.2 探活引擎的实现：三种探测器的统一接口
为了不在状态机里堆一堆 if/else，我抽了一个 IProbe 接口，每个探测类型一个实现类。TCP 探测器用 Socket.ConnectAsync 直接连目标端口，HTTP 探测器用 HttpClient 发 GET 请求检查状态码，ICMP 探测器用 Ping 类发送回显请求。
三个实现类的核心方法都会返回布尔值，统一表示“这次探测是否成功”。超时时间单独设置，默认 TCP 和 HTTP 是 3 秒，ICMP 是 2 秒。超时是探测里最关键的参数，太短容易把慢设备误判为离线，太长又会拖慢整个检测周期。实际使用中我给工控机类的设备把超时放宽到 5 秒，因为现场环境网络质量不如家里稳定。
public interface IProbe { Task<bool> ProbeAsync(DeviceConfig config, CancellationToken ct); } public class TcpProbe : IProbe { public async Task<bool> ProbeAsync(DeviceConfig config, CancellationToken ct) { using var client = new TcpClient(); try { using var timeoutCts = CancellationTokenSource.CreateLinkedTokenSource(ct); timeoutCts.CancelAfter(TimeSpan.FromSeconds(3)); await client.ConnectAsync(config.Host, config.Port, timeoutCts.Token); return true; } catch { return false; } } }HTTP 探测器需要注意空响应和状态码。有些 Web 服务在健康检查端点返回 204 No Content，有些返回 200，如果统一判断必须为 200，会误伤正常服务。所以配置文件里把 expectedStatusCode 做成可配置，默认 200。还有一个常见坑：HttpClient 实例不能频繁创建，要在探活引擎里做成单例，并设置合理的超时和连接池大小。
5.3 全屏静音控制器的调度逻辑
全屏静音控制器不能阻塞在主监控循环里，它得同时监听前台窗口变化。我把它做成一个独立的后台任务，每 500 毫秒检查一次全屏状态。检测到状态从“非全屏”变为“全屏”时，调用 AudioMuter 记录当前音量和静音状态，然后执行静音；从“全屏”变为“非全屏”时，延迟 500 毫秒再恢复。
这里有一个值得分享的设计：不要用“是否全屏”作为唯一判断依据，而是用“全屏状态的边沿触发”。如果某个应用一直处于全屏状态，程序只需要在刚进入时静音一次，而不是每 500 毫秒重复静音。用边沿触发之后，状态切换的开销变得很小，也能避免和用户手动调节音量冲突。
public class FullScreenMuteController { private readonly AudioMuter _audioMuter; private bool _wasFullScreen; private bool _mutedByUs; private bool _restoreScheduled; public async Task RunAsync(CancellationToken ct) { using var timer = new PeriodicTimer(TimeSpan.FromMilliseconds(500)); while (await timer.WaitForNextTickAsync(ct)) { bool isFullScreen = FullScreenDetector.IsFullScreen(); if (isFullScreen && !_wasFullScreen) { _audioMuter.Initialize(); _mutedByUs = true; _audioMuter.SetMute(true); } else if (!isFullScreen && _wasFullScreen && _mutedByUs) { await Task.Delay(TimeSpan.FromMilliseconds(500), ct); _audioMuter.SetMute(false); _mutedByUs = false; } _wasFullScreen = isFullScreen; } } }真实场景下，这个循环还有个隐藏问题：Windows 会临时创建一些全屏窗口，比如 Win32 弹窗或者 Alt+Tab 切换时的动画窗口，它们可能在极短时间内满足全屏条件，导致短暂静音又恢复。我在正式版本里加了时间门槛：全屏状态必须持续至少 1.2 秒才触发静音，这样能过滤掉大部分瞬态窗口。
5.4 单文件发布与后台服务注册
开发完成后的发布环节，.NET 9 给的好处就体现出来了。直接用 dotnet publish 命令，指定目标运行时和单文件模式，输出就是一个几 MB 的 exe。具体的发布命令是：
dotnet publish -c Release -r win-x64 --self-contained true -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true发布出来的 exe 可以直接拷贝到任意 Windows 机器上运行，不需要目标机器预装 .NET 运行时。如果以后要维护源代码，记得把 AOT 相关的裁剪配置搞清楚，因为 P/Invoke 调用 user32.dll 和 Core Audio 这类动态接口时，裁剪器可能会误删一些反射依赖，需要在 csproj 里显式保留。
注册成 Windows 服务并开机自启，用 sc.exe 就可以了。管理员权限打开命令提示符，执行下面两行：
sc.exe create DeviceMonitor binPath= "C:\tools\DeviceMonitor.exe" start= auto sc.exe start DeviceMonitor如果你更习惯图形界面，也可以用 NSSM 工具，它处理日志重定向和崩溃自动重启更省心。这里提醒一句：如果你的服务跑的是需要图形会话的消息逻辑（比如全屏检测），就不能用 Session 0 隔离的系统服务方式。我的做法是把全屏静音逻辑放在一个前台程序里，探活和通知逻辑放在系统服务里。如果坚持单进程，可以创建一个交互式服务或在启动时用计划任务绑定到当前用户会话，但复杂度会上升。
6. 常见问题与排查记录
6.1 设备频繁误报离线怎么办
这是第一个会遇到的坑。最开始我把阈值设成 Ping 两次失败就算离线，结果有一次无线网络节点抖动，整个局域网内十几台设备全部告警下线，过几分钟又全部恢复，场面非常壮观。后来我把阈值调整方案变成“连续失败次数配置化”，并统计误报现象调整到稳定状态。
解决误报的核心思路是分层判断：先用 TCP 或 HTTP 做精确探测，再配合连续失败阈值，最后加一个“恢复确认”逻辑。比如某设备开始持续失败后，我会主动 Ping 一下网关，如果网关也有问题，说明是局域网或当前主机网络的问题，这时候工具会把告警级别降为“网络异常”，而不是直接报设备离线。这样能把环境因素和设备本身的因素分开。
另外，防火墙设置也容易引起误报。Windows 自带的防火墙默认会阻止外部 Ping，如果你的探活主机和被监控设备之间没有放行 ICMP 规则，Ping 会一直失败。这时候就算设备在线，也会被误判为离线。我的建议是能走 TCP 就走 TCP，尽量不要依赖 Ping；必须用 Ping 时，提前做好防火墙放行或改用其他协议。
6.2 全屏检测不准确的情况
全屏检测最容易出错的地方是在多显示器和某些窗口模式。我测试时发现，Chrome 播放视频时如果开的是“画中画”模式，前台窗口矩形并不会覆盖全屏，但这的确属于“用户在专注看视频”的场景，静音告警依然有用。可惜目前这种场景无法用窗口矩形完全覆盖，所以我加了可选的“进程名单”方式：某些已知的全屏播放进程（比如视频播放器）即使窗口矩形不满足条件，也强制按全屏处理。
另一种情况是游戏采用“无边框窗口”，窗口矩形恰好和屏幕一样大，检测逻辑能识别；但如果游戏是“独占全屏”，在 Windows 8 以后基本不存在这种模式了，所以现代系统下问题不大。我实际遇到最麻烦的是 Windows 的 Alt+Tab 切换动画窗口，它在切换瞬间会短暂占据全屏，导致静音误触发。解决方案就是我上面提过的“持续全屏 1.2 秒后才响应”。
6.3 静音后恢复失败或声音串到别的设备
静音恢复失败主要是默认音频设备切换导致的。用户可能在全屏期间插拔了 USB 耳机，或者 Windows 把默认设备从扬声器切到了显示器。我的 AudioMuter 每次执行前都会重新获取默认端点，而不是复用启动时拿到的实例，这样就避免了句柄失效问题。
还有一个隐蔽的场景：一个程序进入全屏时触发静音，但用户手动把音量调到 20，退出全屏时我的工具直接把 Mute 设为 false，音量会突然回到之前的水平，用户反而觉得“音量突然变大”。后来我改成记录进入全屏时的音量值，恢复时把音量和静音状态一并还原，这才符合直觉。
6.4 通知轰炸和消息乱序
如果不加去重，设备在断网重连期间可能会连续触发多次离线/上线通知。这个问题的根因在状态机里已经基本解决，但还有边缘情况：如果用户在配置文件里把 SuccessThreshold 设成 1，那么只要一次探测成功就会立刻报上线，紧接着下一秒又失败又报离线，通知就会来回轰炸。我的解决方法是通知模块里加了“最小间隔”控制：同一设备的同类通知在 5 分钟内只发送一次，即使状态机翻转多次，也只保留第一条和最后一条消息。
消息乱序则是另一个问题。状态变化通知发送是异步的，两个不同通道发送顺序不可控，Webhook 可能比控制台更早送达。这本身不影响正确性，但如果你把通知记录到文件，会看到时间戳乱序。我通过给每条通知加了一个全局递增 ID 来保留逻辑顺序，排查问题时会方便很多。
附：一点算不上总结的收尾经验
这东西在别人看来很小，但实际维护下来我学到最多的反而不是技术，而是“一个工具要能长期跑下去，必须少产生噪音”。最初版本几乎每个状态变化都告警，结果一周后我就开始无视通知了，这和数据安全里的警报疲劳一模一样。后来我把误报率压到最低，通知数量大幅减少，反而每次来消息我都愿意看一眼。
如果你也想做类似的东西，我的建议是从最小功能开始：先只做探活，把通知通道挂上，跑一周输出日志，研究哪些设备经常抖动，再去调阈值；全屏静音属于增量功能，等基础稳定了再加不迟。另外配置文件的注释一定要写清楚，几个月后你自己回来看，也不用靠回忆猜某个字段是什么含义。现在这台工具我已经连续跑了大半年，唯一一次漏报是探活主机本身断电，属于所有监控方案的共同盲区，多部署一个备用探活点就能解决。
