Import-Module失败时如何阻止加载.psd1的RequiredModules及相关疑问

场景重现 #

当PowerShell模块导入失败时，.psd1清单中定义的RequiredModules仍会被加载，以下是具体示例：

模块文件内容 #

MyModule.psd1

@{
    RootModule = 'MyModule.psm1'
    ModuleVersion = '1.0.0.0'
    GUID = '5b058fa7-5248-4a9a-b0f3-75ba6e3a123c'
    Author = 'Author'
    PowerShellVersion = '5.1'
    RequiredModules = @('NetConnection')
    ScriptsToProcess = @('RunFirst.ps1')
    PrivateData = @{ PSData = @{} }
}

RunFirst.ps1

#Requires -RunAsAdministrator

# <执行各类检查，初始化环境>

导入前模块列表 #

PS C:\MyModule> Get-Module
ModuleType Version    Name
---------- -------    ----
Manifest   3.1.0.0    Microsoft.PowerShell.Management
Manifest   3.1.0.0    Microsoft.PowerShell.Utility
Script     2.3.5      PSReadline

非管理员控制台导入失败 #

PS C:\MyModule> Import-Module .\MyModule.psd1

Import-Module : The script 'RunFirst.ps1' cannot be run because it contains a "#requires"
statement for running as Administrator. The current Windows PowerShell session is not running
as Administrator. Start Windows PowerShell by using the Run as Administrator option, and then
try running the script again.

导入失败后模块列表 #

PS C:\MyModule> Get-Module
ModuleType Version    Name
---------- -------    ----
Manifest   3.1.0.0    Microsoft.PowerShell.Management
Manifest   3.1.0.0    Microsoft.PowerShell.Utility
Manifest   2.0.0.0    NetConnection  <----- 如何阻止该模块加载？
Script     2.3.5      PSReadline

问题 #

1. 是否有可靠方法在Import-Module失败时阻止RequiredModules加载，或通过编程卸载这些模块？
2. 附带问题：由于#Requires语句适用于脚本，RunFirst.ps1是模块中放置#Requires -RunAsAdministrator的最合适位置吗？

注：这不是X/Y问题，仅用该场景展示Import-Module失败，实际存在多种失败场景，不同场景会影响方案选择。

解答 #

问题1：阻止RequiredModules加载或失败后卸载 #

PowerShell原生导入流程中，RequiredModules会在执行ScriptsToProcess之前加载，无法直接拦截依赖模块的预加载，但可以通过两种方案解决：

方案1：手动管控依赖加载（推荐）

• 从.psd1清单中移除RequiredModules配置
• 在模块初始化的前置检查通过后，手动导入依赖模块。比如在RunFirst.ps1中先完成权限验证，再加载依赖：

  # RunFirst.ps1内容
  $currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
  if (-not $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
      throw "需要以管理员身份运行才能导入MyModule"
  }
  # 验证通过后再加载依赖
  Import-Module NetConnection -ErrorAction Stop
  

  这种方式完全掌控依赖加载时机，只有前置检查全部通过才会加载依赖，从根源避免失败后残留依赖的问题。

方案2：失败后自动清理已加载的依赖

如果必须保留清单中的RequiredModules，可以封装导入逻辑实现失败后的清理：

function Import-MyModule {
    # 记录导入前已加载的模块名单
    $preLoaded = (Get-Module).Name
    try {
        Import-Module .\MyModule.psd1 -ErrorAction Stop
    }
    catch {
        # 筛选出本次导入新增的依赖模块并卸载
        $newLoaded = (Get-Module).Name | Where-Object { $_ -notin $preLoaded -and $_ -eq 'NetConnection' }
        $newLoaded | ForEach-Object {
            Remove-Module $_ -Force -ErrorAction SilentlyContinue
        }
        # 抛出原错误信息
        throw $_
    }
}

注意：该方案有局限性，如果依赖模块存在嵌套依赖，或其他会话/脚本正在使用该模块，强制卸载可能引发问题，需精确匹配要清理的模块。

问题2：#Requires -RunAsAdministrator的最佳放置位置 #

RunFirst.ps1是合适的位置，但并非唯一选项，可根据需求选择：

• RunFirst.ps1：利用原生#Requires机制，能在模块导入初期快速拦截不符合要求的环境，缺点是错误提示为脚本级，和模块导入的错误风格不一致。
• 模块根文件（MyModule.psm1）开头：用代码手动检查权限，可自定义错误信息，流程控制更灵活：

  # MyModule.psm1开头代码
  $currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
  if (-not $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
      throw "导入MyModule需要管理员权限，请重新以管理员身份启动PowerShell"
  }
  

• 模块清单本身不支持直接配置管理员权限要求，必须通过脚本或模块代码实现验证。

综合来看，若想使用原生#Requires机制，RunFirst.ps1是最直接的选择；若需要更灵活的错误处理，在模块根文件开头手动检查会更合适。

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