编辑希望在这里根据-file接受输入的错误假设来澄清我的问题和误导性问题。感谢您直指我并指出它只是一个switch参数；在我的示例中，输入实际上传递给-path。听起来这可能是搜索多种文件类型的最快的纯Powershell方法，因为-filter仅接受单个输入，而-include则较慢。

get-childItem文档说："过滤器比其他参数更有效，因为提供程序在检索对象时会应用它们，而不是让Windows PowerShell在检索到对象后对它们进行过滤。"

v3设置了带有-file参数的新参数，该参数可能意味着排除目录，以匹配cmd.exe的dir /a:-d

与-include类似，与-filter不同，-file接受多个，如gci -file"*.ldf","*.bak"

因此，我想知道，到目前为止，从性能的角度来看，-file是像-filter一样，即"更有效"，还是更像是"其他参数"(如-include)，因此未能可靠地进行测试。如果-file是一个过滤器，那很好，因为afaict -filter一次只能处理一个过滤器，因此，如果要使用多个过滤器(例如* .ldf和* .bak)，则需要运行两次gci -filter或使用-包括代替。所以我想知道-file是否可以让我们为多个过滤器获得过滤器的效率优势。

我偶然发现了一些使我感到乐观的错误文本。 -file参数希望-path作为当前目录，因此此gci -path $path -file"*.bak","*.ldf"给出错误。推送位置似乎是一个可行的解决方法，但在这里我对错误文本的内容更感兴趣：

Get-ChildItem：无法将" System.Object []"转换为参数" Filter"所需的类型" System.String"。不支持指定的方法。

我调用了-file，但该错误抱怨"参数'Filter'"。那么-file像过滤器一样有效吗？ OTOH，-filter不需要-path作为当前目录，因此在这方面-file更像-include。

仅一种精度：

-file是switch parameter(与-directory相同)，并且不接受值(要仅获取文件，请使用File参数并省略Directory参数。要排除文件，请使用Directory参数并忽略File参数 ); 然后"*.bak","*.ldf"作为值隐式传递给-filter，并且filter仅接受string而不接受string[]。 这就是您的错误出处。

关于性能：使用-file或-directory比使用where-object psiscontainer或? { !$_.psiscontainer}更快，因为它是在提供程序(在这种情况下为文件系统)级别完成的。