Using Module 加载时为何会因 Import-LocalizedData 报错？

结论

仅凭这段报错，无法确认 ArgumentOutOfRangeException 的具体内部原因，也无法判断它是否属于 Using Module 的正式行为或未文档化行为。可以确认的是，异常发生在加载包含类定义的模块时；报告中的模块在顶层调用了 Import-LocalizedData，改用 Import-Module 后则不再报错。一种可行的规避方式是让模块顶层只设置默认值，并将本地化数据的加载放到显式调用的初始化函数中。

延后加载本地化数据

模块先设置默认消息，再定义初始化函数：

$script:Messages = @{
    foo = '<default fallback>'
}

function Initialize-TestUsingModule {
    try {
        Import-LocalizedData `
            -BindingVariable Messages `
            -Filename 'testUsingModule-msg' `
            -ErrorAction Stop
    }
    catch {
        # 本地化数据不可用时保留默认消息。
    }
}

class xClass {
    [string]$foo

    xClass() {
        $this.foo = $script:Messages.foo
    }

    xClass([string]$foo) {
        $this.foo = $foo
    }
}

在使用模块的脚本中，先调用初始化函数，再创建对象：

Using Module testUsingModule

Initialize-TestUsingModule

$x = [xClass]::new()
Write-Host $x.foo

$x = [xClass]::new('bar')
Write-Host $x.foo

这样，本地化数据的查找会从模块加载阶段推迟到脚本显式调用初始化函数时。如果资源文件不可用，导入失败，初始化函数会保留默认值。请检查实际模块中 Import-LocalizedData 对 Messages 的绑定结果是否符合预期。

关于 try/catch 和 Import-Module

try/catch 通常用于捕获终止错误；-ErrorAction Stop 可以将许多非终止错误提升为终止错误。不过，题目中的异常发生在 Using Module 加载流程中。现有信息无法说明它为何没有被模块内的处理逻辑捕获，也无法定位到特定的 PowerShell 缺陷。因此，单纯增加 try/catch 不能视为已经验证的修复。

如果脚本不依赖 Using Module 提供类定义，可以继续评估 Import-Module。如果需要在脚本中直接使用模块定义的类，则应保留 Using Module，并避免在模块顶层执行可能失败的本地化资源查找。还需确保所需的 .psd1 资源文件及目录结构与当前 UI culture 匹配。题目没有提供文件布局，因此无法进一步判断资源不可用的原因。

备注：内容仅供参考。