Windows 桌面程序为什么不应该自己执行高权限保护动作

一个 Windows 桌面工具既要与用户交互，又要处理需要管理员权限的系统动作时，最省事的做法是让整个界面以管理员身份运行。这也是风险最难控制的做法：网页控件、文件选择器和大量用户输入都被带进了高权限进程。

更稳妥的边界是把交互和系统动作分开。普通用户进程只提交结构化请求，高权限服务只接受有限的命令集，然后重新校验参数和目标归属。管道只是传输层，不是信任边界；“请求来自本机”也不等于“请求可以执行”。

用户会话（普通权限）
  UI -> 命令白名单 -> 本地 IPC -> 身份/参数校验
                                      -> 系统服务（高权限）
                                      -> 结构化结果

服务端处理时，可以把命令映射到明确的函数，而不是接收一段命令行或脚本。

return request.Kind switch
{
   
    "QueryStatus" => QueryStatus(),
    "ProtectNow"  => ValidateThenProtect(request),
    _              => Result.Rejected("unsupported_command")
};

这种拆分还有一个实用优点：界面崩溃或退出时，系统状态不会跟着失去所有者。参与超级看门狗 SuperWatchDog 开发时，我们也把“用户想做什么”和“系统允许做什么”当作两次独立判断。具体工程里，命名管道的 ACL、请求大小上限、超时、重放和错误分类都需要单独测试，不能只验证“能连上”。