Win10环境下.NET 6.0后台运行应用如何发送桌面通知

纯控制台应用无法正常发送Windows Toast通知的核心原因是：Windows 通知中心要求发送通知的进程必须关联已注册的应用用户模型ID（AUMID），且具备可被系统激活的入口，无打包、无注册的纯控制台进程发送的通知会被系统直接静默丢弃，不存在稳定的hack方案绕开这个限制。

按实现成本、稳定性排序：

• 首选：.NET 6 WPF/WinForms 非打包桌面应用
  无需做MSIX打包、部署简单，只需要手动注册专属AUMID即可正常发送通知，支持最小化到托盘后台常驻，是实现这类定时巡检+通知需求性价比最高的选项。
• 次选：MSIX打包的Windows App SDK（WinUI3）/WPF/WinForms应用
  打包过程会自动向系统注册AUMID，通知相关的API支持最完整，支持通知交互、进度展示等高级特性，缺点是打包部署流程相对繁琐，需要用户信任安装包证书。
• 服务化方案：Windows 服务 + 轻量用户态托盘进程
  适合需要7*24小时常驻、不被用户误关闭的场景：Windows 服务负责定时调用API做规则判断，检测到触发条件时通过命名管道/本地IPC把通知消息发给跑在用户桌面会话下的托盘进程，由托盘进程完成通知弹出。注意：Windows服务默认运行在会话0隔离层，直接在服务进程内发通知永远无法到达用户桌面，必须拆分用户态进程做通知下发。

按功能场景分类：

• 通知能力
  • Microsoft.Toolkit.Uwp.Notifications：微软官方维护的通知构造库，兼容.NET 6+，无需引用UWP SDK即可快速构造支持文本、按钮、输入框、进度条的Toast通知，自动适配打包/非打包场景，是Windows平台通知开发的首选库。
  • DesktopNotifications：跨平台原生通知库，一套API同时支持Windows、macOS、Linux的系统原生通知，后续需要适配非Windows系统时可以优先选这个。
• 定时调度
  • PeriodicTimer：.NET 6 原生内置的定时器，不存在传统Timer的重入问题，对于固定间隔轮询API的场景完全够用，无需引入第三方依赖。
  • Quartz.NET：如果需要支持cron表达式、多任务调度、任务错过补偿等复杂调度规则，可以选这个成熟的开源调度库，原生支持.NET 6依赖注入。
• 常驻交互
  • Hardcodet.NotifyIcon.Wpf：WPF平台最成熟的托盘图标库，支持右键菜单、状态切换，用来实现窗口隐藏、后台常驻的交互逻辑；WinForms平台可直接使用框架自带的NotifyIcon控件，无需额外引入依赖。
• API调用
  • 直接使用.NET 6内置的IHttpClientFactory创建HttpClient实例即可，内置了生命周期管理、重试策略配置能力，不需要引入第三方HTTP客户端库。

1. 非打包应用一定要在程序启动的第一时间注册专属AUMID，否则通知会被系统拦截，注册代码参考：

// 程序启动入口执行，AUMID保证全局唯一即可，格式建议为[厂商].[应用名]_[版本号]
const string AppAumid = "Custom.ApiMonitor_1.0.0";
DesktopNotificationManagerCompat.RegisterAumid(AppAumid);

2. 定时轮询逻辑必须加全局异常捕获，API请求超时、返回格式异常等问题不能导致程序直接崩溃；建议给请求加合理的间隔时间，避免对目标API造成不必要的压力。
3. 如果需要处理用户点击通知的交互逻辑，需要提前订阅通知激活事件，否则用户点击通知不会有任何反馈。
4. 不要尝试在控制台应用、Windows服务进程内直接发送通知，这两类场景的限制是系统层面的，没有稳定的绕开方案。

1. 新建.NET 6 WPF项目，通过Nuget安装Microsoft.Toolkit.Uwp.Notifications、Hardcodet.NotifyIcon.Wpf两个包
2. 在App.xaml.cs的启动逻辑中注册AUMID，初始化托盘图标，设置主窗口默认隐藏
3. 启动后台异步任务，用PeriodicTimer按预设间隔调用目标API，校验返回结果是否满足通知触发条件
4. 满足触发条件时构造Toast通知内容，调用通知API完成下发
5. 订阅通知激活事件，处理用户点击通知后的跳转、逻辑触发操作

内容的提问来源于stack exchange，提问作者sJames