家里和公司加起来不到十台设备平时没人守着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 Listint _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 { Taskbool ProbeAsync(DeviceConfig config, CancellationToken ct); } public class TcpProbe : IProbe { public async Taskbool 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 弹窗或者 AltTab 切换时的动画窗口它们可能在极短时间内满足全屏条件导致短暂静音又恢复。我在正式版本里加了时间门槛全屏状态必须持续至少 1.2 秒才触发静音这样能过滤掉大部分瞬态窗口。5.4 单文件发布与后台服务注册开发完成后的发布环节.NET 9 给的好处就体现出来了。直接用 dotnet publish 命令指定目标运行时和单文件模式输出就是一个几 MB 的 exe。具体的发布命令是dotnet publish -c Release -r win-x64 --self-contained true -p:PublishSingleFiletrue -p:IncludeNativeLibrariesForSelfExtracttrue发布出来的 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 的 AltTab 切换动画窗口它在切换瞬间会短暂占据全屏导致静音误触发。解决方案就是我上面提过的“持续全屏 1.2 秒后才响应”。6.3 静音后恢复失败或声音串到别的设备静音恢复失败主要是默认音频设备切换导致的。用户可能在全屏期间插拔了 USB 耳机或者 Windows 把默认设备从扬声器切到了显示器。我的 AudioMuter 每次执行前都会重新获取默认端点而不是复用启动时拿到的实例这样就避免了句柄失效问题。还有一个隐蔽的场景一个程序进入全屏时触发静音但用户手动把音量调到 20退出全屏时我的工具直接把 Mute 设为 false音量会突然回到之前的水平用户反而觉得“音量突然变大”。后来我改成记录进入全屏时的音量值恢复时把音量和静音状态一并还原这才符合直觉。6.4 通知轰炸和消息乱序如果不加去重设备在断网重连期间可能会连续触发多次离线/上线通知。这个问题的根因在状态机里已经基本解决但还有边缘情况如果用户在配置文件里把 SuccessThreshold 设成 1那么只要一次探测成功就会立刻报上线紧接着下一秒又失败又报离线通知就会来回轰炸。我的解决方法是通知模块里加了“最小间隔”控制同一设备的同类通知在 5 分钟内只发送一次即使状态机翻转多次也只保留第一条和最后一条消息。消息乱序则是另一个问题。状态变化通知发送是异步的两个不同通道发送顺序不可控Webhook 可能比控制台更早送达。这本身不影响正确性但如果你把通知记录到文件会看到时间戳乱序。我通过给每条通知加了一个全局递增 ID 来保留逻辑顺序排查问题时会方便很多。附一点算不上总结的收尾经验这东西在别人看来很小但实际维护下来我学到最多的反而不是技术而是“一个工具要能长期跑下去必须少产生噪音”。最初版本几乎每个状态变化都告警结果一周后我就开始无视通知了这和数据安全里的警报疲劳一模一样。后来我把误报率压到最低通知数量大幅减少反而每次来消息我都愿意看一眼。如果你也想做类似的东西我的建议是从最小功能开始先只做探活把通知通道挂上跑一周输出日志研究哪些设备经常抖动再去调阈值全屏静音属于增量功能等基础稳定了再加不迟。另外配置文件的注释一定要写清楚几个月后你自己回来看也不用靠回忆猜某个字段是什么含义。现在这台工具我已经连续跑了大半年唯一一次漏报是探活主机本身断电属于所有监控方案的共同盲区多部署一个备用探活点就能解决。