接口是已定义可用功能的抽象集合。

该接口中的方法是否表现为静态行为是应该隐藏在接口后面的实现细节。将接口方法定义为静态是错误的，因为您将不必要地强制该方法以某种方式实现。

如果方法被定义为静态的，那么实现接口的类就不会像它应该的那样被封装。在面向对象设计中，封装是一件值得努力的事情(我不会详细说明原因，你可以在这里阅读:http://en.wikipedia.org/wiki/Object-oriented)。因此，在接口中不允许使用静态方法。

静态类应该能够做到这一点，这样它们就可以被通用地使用。我不得不实现一个Singleton来实现预期的结果。

我有一堆静态业务层类，实现了CRUD方法，如“创建”，“读取”，“更新”，“删除”的每个实体类型，如“用户”，“团队”等。然后，我为实现CRUD方法的业务层类创建了一个具有抽象属性的基本控件。这让我可以自动从基类中执行“创建”、“读取”、“更新”、“删除”操作。由于静态限制，我不得不使用单例。

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

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

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

在接口代表“契约”的程度上，静态类实现接口似乎是非常合理的。

上述论点似乎都忽略了合同的这一点。

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

你怎么称呼它??

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;  

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