我完全懂你这种纠结——为了避开PowerShell函数参数绑定器的性能瓶颈转用类，结果又舍不得命名参数带来的代码可读性，毕竟一堆位置参数堆在一起，过段时间回头看真的头大。

首先得说清楚：你直接写[A]::method($a="a", $b="b")之所以不行，是因为类方法本质遵循.NET的调用规则，而PowerShell里那种-ParamName Value或者$ParamName=Value的命名参数语法，是PowerShell专属给函数、脚本和脚本块设计的，.NET方法调用不支持这种写法。不过咱们有完美的替代方案，而且完全不影响你要的性能优势。

最推荐也是我日常用得最多的方法，就是哈希表+Splatting（参数展开）：

class A {
    static [void] Method([string]$a, [string]$b) {
        Write-Host "$a $b"
    }
}

# 用哈希表定义命名参数，键和方法的参数名严格对应
$methodParams = @{
    a = "Hello"
    b = "World"
}

# 用@符号展开哈希表，传给类方法
[A]::Method(@methodParams)

这种方式既保留了命名参数的可读性——每个参数对应的值一目了然，不用记参数顺序；又完全不会触发函数那种参数绑定器的额外开销，类方法的性能优势能完全保留。

如果是临时调用、参数不多的场景，还可以用更紧凑的内联写法：

# 内联哈希表直接展开调用
[A]::Method(@{ a = "Quick"; b = "Demo" })

另外补充个小细节：如果你的类方法定义了可选参数（带默认值），哈希表里只需要传你想指定的参数，没传的会自动用方法定义的默认值，逻辑和PowerShell函数的命名参数完全一致。

最后给你提个避坑点：千万别想着用PowerShell函数封装类方法来“蹭”命名参数——那又绕回你最初的性能问题了，完全没必要。就用splatting，简洁高效，完美平衡可读性和性能，亲测各种场景都好用！