windows服务无法直接操作桌面会话，因其运行在session 0而用户应用在session 1+，受系统隔离机制限制；推荐使用命名管道通信，服务端监听、桌面客户端连接，支持json或文本协议，轻量可控且无需额外依赖。
Windows服务无法直接操作桌面会话
Windows服务默认运行在 Session 0，而用户登录后的桌面应用在 Session 1（或更高），两者隔离。这意味着 MessageBox.Show()、Process.Start("notepad.exe")、甚至直接调用 UI 线程都会静默失败或抛出 InvalidOperationException（“无法在非交互式服务中执行请求的操作”）。
这不是权限问题，而是 Windows 的 Session 隔离机制强制要求。绕过它（如启用“允许服务与桌面交互”）在 Win10/Win11 中已被禁用，且存在安全风险，不推荐。
推荐方案：命名管道（NamedPipeServerStream / NamedPipeClientStream）
这是最轻量、最可控、无需额外依赖的进程间通信方式，适合服务 ↔ 同一机器上用户会话中的桌面应用通信。
- 服务端（Windows Service）创建
NamedPipeServerStream，监听固定管道名（如"\.pipeMyServicePipe"） - 桌面应用启动后，用
NamedPipeClientStream连接该管道，发送/接收 JSON 或简单文本协议 - 注意：服务需以
LocalSystem或具有适当权限的账户运行；桌面应用必须在用户登录后运行，否则连接会超时 - 示例关键片段（服务端）：
var server = new NamedPipeServerStream("MyServicePipe", PipeDirection.InOut, maxNumberOfServerInstances: 1);记得用await server.WaitForConnectionAsync()避免阻塞服务主线程
替代方案：Windows消息（WM_COPYDATA）不适用于服务
虽然桌面应用之间常用 SendMessage + WM_COPYDATA 传递数据，但 Windows 服务无法获取用户会话的窗口句柄（FindWindow 返回 0），也无法调用 PostMessage 到用户桌面进程——因为服务没有 GUI 线程上下文，且窗口属于另一 Session。
强行尝试会返回错误码 ERROR_ACCESS_DENIED 或 0（无效句柄）。不要在此方向浪费时间。
高级场景：需要跨用户或远程？考虑 WCF 或 HTTP API
如果桌面应用可能由不同用户运行，或未来要支持网络调用，硬编码管道名就不够用了。此时可让服务启动一个本地 HTTP 监听器（如 HttpListener 或 Microsoft.AspNetCore.Hosting 轻量宿主），绑定到 http://127.0.0.1:5000/。
- 桌面应用用
HttpClient发送 REST 请求（GET/POST），服务返回 JSON - 比管道更易调试（可用 curl / Postman 测试），也天然支持多客户端并发
- 注意：需配置防火墙例外（仅限 localhost）；若用
HttpListener，需提前用netsh http add urlacl授权服务账户访问该地址
真正容易被忽略的是 Session 切换时的连接重建逻辑——比如用户锁屏再解锁，桌面应用可能被回收或重连失败，服务端需容忍客户端断连并保持监听循环，而不是假设一次连接永久有效。
