虽然您的问题表明它是针对“通用OO”的，但它似乎真正关注的是.NET对这些术语的使用。

在.NET中（类似于Java）：

接口可以没有状态或实现实现接口的类必须提供该接口的所有方法的实现抽象类可以包含状态（数据成员）和/或实现（方法）抽象类可以在不实现抽象方法的情况下继承（尽管这样的派生类本身是抽象的）接口可能是多继承的，抽象类可能不是（这可能是接口与abtract类分开存在的关键具体原因——它们允许实现多继承，从而消除了一般MI的许多问题）。

作为通用OO术语，差异不一定定义明确。例如，有些C++程序员可能持有类似的严格定义（接口是抽象类的严格子集，不能包含实现），而有些人可能会说，具有某些默认实现的抽象类仍然是接口，或者非抽象类仍然可以定义接口。

事实上，有一种叫做非虚拟接口（NVI）的C++习惯用法，其中公共方法是“thunk”到私有虚拟方法的非虚拟方法：

http://www.gotw.ca/publications/mill18.htmhttp://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-虚拟界面（_I）

第二个问题的答案：接口中定义的公共变量默认为静态final，而抽象类中的公共变量为实例变量。

抽象类处理有效地打包类功能，而接口用于意图/契约/通信，并且应该与其他类/模块共享。

使用抽象类作为契约和（部分）契约实现者违反了SRP。使用抽象类作为契约（依赖关系）限制了创建多个抽象类以获得更好的重用性。

在下面的示例中，使用抽象类作为OrderManager的合同会产生问题，因为我们有两种不同的处理订单的方式-基于客户类型和类别（客户可以是直接或间接的，也可以是黄金或白银）。因此，接口用于契约，抽象类用于不同的工作流实施

public interface IOrderProcessor
{
    bool Process(string orderNumber);
}

public abstract class CustomerTypeOrderProcessor: IOrderProcessor
{
    public bool Process(string orderNumber) => IsValid(orderNumber) ? ProcessOrder(orderNumber) : false;

    protected abstract bool ProcessOrder(string orderNumber);

    protected abstract bool IsValid(string orderNumber);
}

public class DirectCustomerOrderProcessor : CustomerTypeOrderProcessor
{
    protected override bool IsValid(string orderNumber) => string.IsNullOrEmpty(orderNumber); 

    protected override bool ProcessOrder(string orderNumber) => true; 
}

public class InDirectCustomerOrderProcessor : CustomerTypeOrderProcessor
{
    protected override bool IsValid(string orderNumber) => orderNumber.StartsWith("EX");

    protected override bool ProcessOrder(string orderNumber) => true;
}

public abstract class CustomerCategoryOrderProcessor : IOrderProcessor
{
    public bool Process(string orderNumber) => ProcessOrder(GetDiscountPercentile(orderNumber), orderNumber);

    protected abstract int GetDiscountPercentile(string orderNumber);

    protected abstract bool ProcessOrder(int discount, string orderNumber);
}

public class GoldCustomer : CustomerCategoryOrderProcessor
{
    protected override int GetDiscountPercentile(string orderNumber) => 15;

    protected override bool ProcessOrder(int discount, string orderNumber) => true;

}

public class SilverCustomer : CustomerCategoryOrderProcessor
{
    protected override int GetDiscountPercentile(string orderNumber) => 10;

    protected override bool ProcessOrder(int discount, string orderNumber) => true;

}

public class OrderManager
{
    private readonly IOrderProcessor _orderProcessor;// Not CustomerTypeOrderProcessor or CustomerCategoryOrderProcessor 

    //Using abstract class here would create problem as we have two different abstract classes
    public OrderManager(IOrderProcessor orderProcessor) => _orderProcessor = orderProcessor;
}

接口定义服务或服务集的契约。它们以水平方式提供多态性，因为两个完全不相关的类可以实现相同的接口，但可以互换地用作它们实现的接口类型的参数，因为这两个类都承诺满足接口定义的服务集。接口没有提供实现细节。

抽象类为其子类和可选的部分实现定义了基结构。抽象类以垂直但定向的方式提供多态性，因为继承抽象类的任何类都可以被视为该抽象类的实例，而不是相反。抽象类可以而且经常包含实现细节，但不能单独实例化——只有它们的子类可以“更新”。

注意，C#也允许接口继承。

从概念上讲，保持特定于语言的实现、规则、好处，并通过使用任何人或两者实现任何编程目标，可以或不可以有代码/数据/属性等等，单继承或多继承等等

1-抽象（或纯抽象）类旨在实现层次结构。如果您的业务对象在结构上看起来有些相似，仅表示父子（层次结构）类型的关系，那么将使用继承/抽象类。如果您的业务模型没有层次结构，那么就不应该使用继承（这里我不是在谈论编程逻辑，例如一些设计模式需要继承）。从概念上讲，抽象类是一种在OOP中实现业务模型层次结构的方法，它与接口无关，实际上将抽象类与接口进行比较是没有意义的，因为两者在概念上完全不同，在访谈中要求它只是为了检查概念，因为当涉及到实现时，它看起来都提供了一些相同的功能，而我们程序员通常更强调编码。[请记住，抽象与抽象类不同]。

2-接口是一个契约，一个由一组或多组功能表示的完整业务功能。这就是它被实现而不是继承的原因。业务对象（是否是层次结构的一部分）可以具有任意数量的完整业务功能。它与抽象类无关，通常意味着继承。例如，人可以跑步，大象可以跑步，鸟可以跑步等等，所有这些不同层次的对象都将实现RUN接口或EAT或SPEAK接口。不要进入实现，因为您可能会将其实现为为实现这些接口的每种类型提供抽象类。任何层次结构的对象都可以具有与其层次结构无关的功能（接口）。

我相信，接口的发明并不是为了实现多重继承或公开公共行为，类似地，纯抽象类并不是为了推翻接口，而是接口是一个对象可以实现的功能（通过接口的功能），抽象类代表一个层次结构的父级，以生成具有父级核心结构（属性+功能）的子级

当你被问到差异时，这实际上是概念上的差异，而不是特定语言实现中的差异，除非被明确问到。

我相信，两位面试官都希望这两者之间有一条直线的直接区别，当你失败时，他们试图通过将“一个作为另一个”来驱使你实现这一区别

如果你有一个只有抽象方法的抽象类呢？

打个比方吧：当我在空军时，我参加了飞行员培训，成为了一名美国空军飞行员。当时我没有资格驾驶任何飞机，必须参加飞机类型的训练。一旦我获得资格，我就是一名飞行员（抽象类）和一名C-141飞行员（具体类）。在我的一项任务中，我被赋予了一项额外的职责：安全员。现在我仍然是一名飞行员和C-141飞行员，但我也履行了安全员的职责（可以说，我执行了ISafetyOfficer）。飞行员不需要是安全员，其他人也可以这样做。

所有美国空军飞行员都必须遵守某些空军规定，所有C-141（或F-16或T-38）飞行员都是“美国空军飞行员”。任何人都可以成为安全员。因此，总结如下：

Pilot：抽象类C-141试验：混凝土等级ISafety Officer:接口

补充说明：这是一个类比，以帮助解释概念，而不是编码建议。看到下面的各种评论，讨论很有趣。