接口多态的核心是运行时通过统一接口类型安全调用不同实现类的行为，前提为所有实现类均以接口类型被引用且方法签名与访问性严格一致；它不依赖继承链，仅靠契约一致性实现解耦调用。
接口多态在 C# 里不是“怎么写出来”的问题，而是“怎么让调用方完全不知道具体类型，还能安全调用行为”的问题。它成立的前提只有一个：所有实现类都通过同一接口类型被引用，且该接口方法在运行时能正确分发到各自实现——这和 abstract class 的 virtual/override 机制无关，不依赖继承链，只依赖契约一致。
为什么 new 出来对象却没走多态？
常见错误是写了 ISound sound = new Dog()，但调用 sound.MakeSound() 时发现行为不对，甚至编译报错。根本原因往往不是代码逻辑，而是接口或实现类的声明细节没对齐：
-
ISound中方法没加访问修饰符（C# 要求接口成员必须是public，但不能显式写public；若误写成private void MakeSound()，直接编译失败） - 实现类里用了
void MakeSound()，但漏了public——C# 默认是private，导致该方法不是接口的公开实现，编译器报错：'Dog.MakeSound()' does not implement interface member 'ISound.MakeSound()' - 接口方法签名是
void MakeSound(string volume)，而实现类写成了public void MakeSound()（少参数），签名不一致，多态断开
interface 和 abstract class 在多态中到底谁更“轻”？
接口多态更轻量、更解耦，因为它不要求类型之间有继承关系。一个 Dog、一个 Doorbell、一个 TextToSpeechEngine 完全不相关，只要都实现 ISound，就能放进 ISound[] 里统一调用。抽象类做不到这点——它强制“是某种东西”，比如 Animal 基类下只能放动物，不能塞门铃。
- 接口支持多实现：
class Doorbell : ISound, IButton, IConfigurable→ 一个类型可承载多个独立契约 - 抽象类只能单继承：
class Dog : Animal→ 若还想支持IConfigurable，还得额外实现接口，无法绕过 - 接口默认无字段、无状态，天然适合跨服务、跨域通信（如 gRPC 接口定义、DTO 层契约）
.NET 8 的默认接口方法会破坏多态吗？
不会，但会改变你对“必须实现”的理解。C# 8.0+ 允许在接口里写默认实现，例如：
public interface ISound
{
void MakeSound();
void Stop() => Console.WriteLine("Stopped.");
}
这时 class Dog : ISound 可以不实现 Stop()，直接用默认逻辑。但这不等于多态失效——它只是把“强制实现”降级为“可选覆盖”。真正要注意的是：
- 默认方法不能访问私有字段或调用私有帮助方法（接口仍无状态）
- 若老项目还在 .NET Framework 4.8 或 .NET Core 3.1 上，这种写法直接编译不过
- 子类若想自定义
Stop()，仍需用public void Stop()显式重写，不能用override（接口方法不是 virtual）
最容易被忽略的点是：接口多态不关心“你怎么实现”，只关心“你有没有按契约暴露公开方法”。哪怕内部逻辑天差地别，只要签名对、访问性对、类型对，foreach (ISound s in devices) s.MakeSound(); 就永远可靠。一旦开始纠结“这个该放接口还是抽象类”，先问一句：它们真属于同一类事物，还是仅仅共享一种能力？答案决定了多态的根基稳不稳。
