我猜这是短视。

在最初设计时，接口仅用于类的实例

IMyInterface val = GetObjectImplementingIMyInterface();
val.SomeThingDefinedinInterface();

只有引入接口作为泛型的约束，向接口中添加静态方法才有实际用途。

(回复评论:)我认为现在更改它需要更改CLR，这将导致与现有程序集不兼容。

假设你在问为什么你不能这样做:

public interface IFoo {
    void Bar();
}

public class Foo: IFoo {
    public static void Bar() {}
}

This doesn't make sense to me, semantically. Methods specified on an interface should be there to specify the contract for interacting with an object. Static methods do not allow you to interact with an object - if you find yourself in the position where your implementation could be made static, you may need to ask yourself if that method really belongs in the interface. To implement your example, I would give Animal a const property, which would still allow it to be accessed from a static context, and return that value in the implementation.

public class Animal: IListItem {
    /* Can be tough to come up with a different, yet meaningful name!
     * A different casing convention, like Java has, would help here.
     */
    public const string AnimalScreenName = "Animal";
    public string ScreenName(){ return AnimalScreenName; }
}

对于更复杂的情况，您总是可以声明另一个静态方法并委托给它。在尝试给出一个例子的过程中，我想不出您在静态和实例上下文中都要做一些非平凡的事情的任何理由，因此我将给您一个FooBar blob，并将其作为它可能不是一个好主意的指示。

因为接口是继承结构，静态方法继承不好。

根据面向对象的概念，由类和接口实现 有合同访问这些实现的功能(或方法)使用 对象。

如果你想访问接口契约方法，你必须创建对象。对于静态方法，这是不允许的。静态类、方法和变量永远不需要对象和加载到内存中，而不需要创建该区域(或类)的对象，或者你可以说不需要对象创建。

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

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

例如:

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...
    }
  }
}

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

从概念上讲，接口没有理由不能定义包含静态方法的契约。

对于当前的c#语言实现，限制是由于允许继承基类和接口。如果“类SomeBaseClass”实现了“接口ISomeInterface”和“类SomeDerivedClass: SomeBaseClass, ISomeInterface”也实现了接口，实现接口方法的静态方法将会编译失败，因为静态方法不能与实例方法具有相同的签名(实例方法将出现在实现接口的基类中)。

静态类在功能上与单例类相同，并且具有与单例类相同的目的，只是语法更简洁。因为单例可以实现接口，所以静态的接口实现在概念上是有效的。

因此，这可以简单地归结为c#的实例名称冲突和跨继承的同名静态方法的限制。c#没有理由不能“升级”以支持静态方法契约(接口)。