出于安全性考虑，Windows本身禁止非提升进程和提升进程共享控制台。因此，从非提升进程启动的提升（控制台-子系统）进程 * 总是 * 在 * 新的 * 控制台窗口中运行。

只有**次优的，非平凡的 * 解决方法 * 需要一个 * 助手可执行文件 * 来 Package 提升的进程。
有关所涉及的权衡，请参见底部部分。

**gsudo.exe**就是这样一个helper可执行文件，您可以通过winget.exe安装，具体如下：

# Note: Requires elevation (admin privileges) to install; prompts on demand.
#       Installs gsudo.exe as well as an effective alias, sudo.exe (via a symlink)
winget install gerardog.gsudo

字符串
虽然gsudo同样适用于cmd.exe甚至WSL，但它对来自PowerShell的调用提供了**特殊支持 *：

• 注意事项：
• 与目标进程启动 * 提升 * 的关键区别在于，gsudo * 实际上 * 支持与PowerShell CLI相同的语法（powershell.exe用于Windows PowerShell，pwsh用于PowerShell（Core）7+），带有（仅）（隐含）-Command参数。
• 如果您需要对后台使用的PowerShell CLI调用进行更多控制，即传递其他CLI选项，请 * 直接 * 调用CLI;例如gsudo pwsh -NoProfile { net sessions }
• 您可以直接传递.ps1文件路径和参数：

gsudo C:\path\to\file.ps1 arg1 arg2

型

• 注意事项：
• 这总是只支持 text 输出;对于富类型支持，使用脚本块，如下所述。
• 此外，由于-Command是在后台使用的，因此传递参数，即使在调用方作为 * 逐字 * 字符串传递时，也会受到被调用方 * 的解释 *;例如，gsudo C:\path\to\file.ps1 '$HOME'仍然扩展为$HOME变量的值，即在提升的过程中;您可以通过-File而不是-Command（例如gsudo pwsh -File C:\path\to\file.ps1 '$HOME'）进行 explicit CLI调用来避免此问题，或者再次使用下面讨论的脚本块方法。
• 您甚至可以传递script blocks（{ ... }），在这种情况下，您可以获得 * 丰富类型支持 * 的好处，尽管 * 有限的类型保真度 *，就像涉及 * 跨进程序列化 * 的情况一样。

# Outputs a deserialized [System.Diagnostics.Process] instance, 
# i.e. an *emulation* of the original object with static copies of
# its properties.
gsudo { Get-Process -IncludeUserName $args[0] } -Args winlogon

型

• 与上面的.ps1调用具有丰富类型支持的等价物是（另外，防止了传递给-Args的传递参数数组的元素的重新解释）：

gsudo { C:\path\to\file.ps1 $args[0] $args[1] } -Args arg1, arg2

型
在变通方法中，有两种相互排斥的方法，每种方法都有自己的优点和缺点-gsudo根据情况使用其中一种方法：

• 使helper可执行 * 将提升的进程直接附加到调用者的控制台**。
• Pro：提供完整的控制台UI体验，例如Vim等全屏控制台应用。
• 缺点：调用者 * 不能 * 访问提升进程的标准流**，即您既不能向其标准输入流发送数据，也不能捕获其标准输出和标准错误流。
• gsudo在启动时使用这种方法 * 不带参数 *，以便进入一个 * 交互式 * 提升的会话。
• 使helper可执行文件运行提升的进程隐藏 *，并通过其标准流**与之通信，默认情况下将提升的进程的stdout和stderr输出打印到调用者的控制台。
• 优点：允许向提升的进程发送输入和捕获输出。
• 缺点：缺乏完整的控制台用户体验;但是，对于自动执行非交互式命令或仅具有简单的基于控制台的用户提示的命令，这并不重要。
• gsudo在您使用命令 * 启动gsudo时使用此方法。

[1]这与PowerShell remoting和后台jobs中使用的基于CLIXML的序列化类型相同。
字体保真度限制在this answer中有详细说明。