最可靠的方式是调用 WindowsIdentity.GetCurrent(true).IsInRole(WindowsBuiltInRole.Administrator)，其中参数 true 强制刷新令牌以获取提升后的权限，避免因 UAC 虚拟化导致误判。
怎么用 WindowsIdentity 和 WindowsPrincipal 判断当前进程是否有管理员权限
最可靠的方式是查当前用户是否属于 BuiltinAdministratorsSid 组，而不是只看用户名或进程名。因为 Windows 的 UAC 机制下，“以管理员身份运行”和“实际拥有管理员组成员资格”是两回事。
实操建议：
- 必须用
WindowsIdentity.GetCurrent(true)（参数true表示强制刷新令牌），否则可能拿到的是未提升的受限令牌 - 用
WindowsPrincipal.IsInRole(WindowsBuiltInRole.Administrator)判断，不要自己解析 SID 字符串 - 在 .NET Core / .NET 5+ 中，
WindowsPrincipal仍可用，但需引用System.Security.Principal.Windows包（.NET 6+ 默认包含）
常见错误现象：IsInRole 返回 false，但程序明明是右键“以管理员身份运行”启动的——大概率是没传 true 给 GetCurrent()，拿到了虚拟化后的标准令牌。
为什么 Process.GetCurrentProcess().StartInfo.Verb == "runas" 不靠谱
这个字段只反映启动时的意图，不是运行时的实际权限状态。UAC 提升后，新进程的 StartInfo 是空的；而且它根本不会被继承到子进程里，调试器、服务托管、IDE 启动等场景下完全不可信。
使用场景：仅适合做启动前的 UI 提示（比如弹窗说“请右键以管理员身份运行”），绝不能用于权限校验逻辑。
性能 / 兼容性影响：读取 StartInfo 几乎无开销，但依赖它做判断会导致权限检查失效，后续操作（如写 C:\Program Files 或修改注册表 HKEY_LOCAL_MACHINE）直接抛 UnauthorizedAccessException。
遇到 UnauthorizedAccessException 才去检查权限？太晚了
异常是结果，不是条件。等写文件失败再提示“需要管理员权限”，用户体验差，且可能已造成部分状态变更（比如日志写了一半、配置改了一半）。
实操建议：
- 在程序入口（
Main方法）或关键功能触发前，就调用权限检查逻辑 - 如果检查失败，可主动调用
Process.Start(new ProcessStartInfo { UseShellExecute = true, Verb = "runas", FileName = Application.ExecutablePath })重启自身（注意传递原始命令行参数） - 避免在检查后、执行前之间出现权限相关操作——这两步之间没有原子性保障
容易踩的坑：有人把权限检查放在某个按钮点击事件里，但没处理“检查通过 → 执行 → 中间被用户关闭 UAC 弹窗”的情况，导致后续操作静默失败。
.NET 6+ 在非 Windows 平台会怎样
WindowsIdentity 和 WindowsPrincipal 在 Linux/macOS 上会抛 PlatformNotSupportedException。如果你写的是跨平台应用，不能无条件调用。
实操建议：
- 先用
OperatingSystem.IsWindows()做守卫 - 非 Windows 下，管理员概念对应 root 用户，可用
Environment.GetEnvironmentVariable("USER") == "root"粗略判断（不严谨但够用），或调用stat /proc/1检查 init 进程 UID（需System.Diagnostics.Process+ shell 调用） - 别在
#if WINDOWS外裸写WindowsIdentity—— 编译不过
真正复杂的地方在于：权限检查本身不难，难的是检查时机、失败后的降级路径、以及多线程/多实例下状态同步。比如一个后台服务进程被提升后，它的子线程是否自动继承？答案是否定的——每个线程都得自己查。
