您想要的是允许通过Type或该类型的任何实例调用静态方法。这至少会导致歧义，这不是一个理想的特征。

关于这是否重要，这是最佳实践，以及这样做是否存在性能问题，将会有无休止的争论。通过简单地不支持它，c#使我们不必担心它。

遵循这一愿望的编译器也可能会失去一些优化，而这些优化可能会带来实例方法和静态方法之间更严格的分离。

我的(简化的)技术原因是静态方法不在虚表中，调用站点是在编译时选择的。这和你不能有覆盖或虚拟静态成员的原因是一样的。要了解更多细节，你需要一个计算机专业毕业生或编译专家——而我两者都不是。

出于政治原因，我将引用Eric Lippert(他是一名编译器专家，拥有滑铁卢大学的数学、计算机科学和应用数学学士学位)的话:

.．.静态方法的核心设计原则，给它们命名的原则是…在编译时，总是可以准确地确定将调用什么方法。也就是说，可以仅通过对代码的静态分析来解析该方法。

请注意，Lippert确实为所谓的类型方法留出了空间:

也就是说，与类型相关联的方法(如静态方法)，它不接受不可空的“this”参数(与实例或虚拟方法不同)，而是调用的方法依赖于T的构造类型(与静态方法不同，它必须在编译时确定)。

但还没有被它的实用性所说服。

一个静态类是用c#实现的，微软用静态元素创建了一个特殊的类实例，这只是实现静态功能的一个奇怪之处。这不是一个理论观点。

接口应该是类接口的描述符——或者它是如何与之交互的，并且应该包括静态的交互。接口的一般定义(来自merriam - webster):不同事物相遇、交流或相互影响的地方或区域。当您完全忽略类的静态组件或静态类时，我们就忽略了这些坏家伙如何交互的大部分内容。

下面是一个非常清晰的例子，说明了在静态类中使用接口是非常有用的:

public interface ICrudModel<T, Tk>
{
    Boolean Create(T obj);
    T Retrieve(Tk key);
    Boolean Update(T obj);
    Boolean Delete(T obj);
}

目前，我在编写包含这些方法的静态类时没有进行任何检查，以确保我没有忘记任何东西。就像在面向对象编程之前的糟糕的编程时代。

c#和CLR应该像Java一样支持接口中的静态方法。静态修饰符是契约定义的一部分，确实有意义，具体来说，行为和返回值不会基于实例而变化，尽管在不同调用之间仍然可能不同。

也就是说，当您想在接口中使用静态方法而又不能使用时，我建议您使用注释。您将得到您正在寻找的功能。

这里的大多数答案似乎都没有抓住重点。多态性不仅可以在实例之间使用，还可以在类型之间使用。当我们使用泛型时，这是经常需要的。

假设我们在泛型方法中有类型参数，我们需要对它做一些操作。我们不想实例化，因为我们不知道构造函数。

例如:

Repository GetRepository<T>()
{
  //need to call T.IsQueryable, but can't!!!
  //need to call T.RowCount
  //need to call T.DoSomeStaticMath(int param)
}

...
var r = GetRepository<Customer>()

不幸的是，我只能想出一些“丑陋”的选择:

Use reflection Ugly and beats the idea of interfaces and polymorphism. Create completely separate factory class This might greatly increase the complexity of the code. For example, if we are trying to model domain objects, each object would need another repository class. Instantiate and then call the desired interface method This can be hard to implement even if we control the source for the classes, used as generic parameters. The reason is that, for example we might need the instances to be only in well-known, "connected to DB" state.

例子:

public class Customer 
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  void SomeOtherMethod() 
  { 
    //do work...
  }
}

为了使用实例化来解决静态接口问题，我们需要做以下事情:

public class Customer: IDoSomeStaticMath
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  //dummy instance
  public Customer() { IsDummy = true; }

  int DoSomeStaticMath(int a) { }

  void SomeOtherMethod() 
  { 
    if(!IsDummy) 
    {
      //do work...
    }
  }
}

这显然是丑陋的，也是不必要的，会使所有其他方法的代码复杂化。显然，这也不是一个优雅的解决方案!

因为接口的目的是允许多态性，能够传递任意数量的已定义类的实例，这些类都已定义，以实现已定义的接口……确保在多态调用中，代码能够找到您正在调用的方法。允许静态方法实现接口是没有意义的，

你怎么称呼它??

public interface MyInterface { void MyMethod(); }
public class MyClass: MyInterface
{
    public static void MyMethod() { //Do Something; }
}

 // inside of some other class ...  
 // How would you call the method on the interface ???
    MyClass.MyMethod();  // this calls the method normally 
                         // not through the interface...

    // This next fails you can't cast a classname to a different type... 
    // Only instances can be Cast to a different type...
    MyInterface myItf = MyClass as MyInterface;