接口用于能力拼装，定义行为契约实现跨类型复用；抽象类用于身份继承，封装共性逻辑支持纵向复用；实际常组合使用，先接口定义契约再抽象类提供默认实现。
接口和抽象类都支持多态，但它们支撑多态的方式和重用逻辑完全不同。选型不是看“哪个更高级”，而是看你要解决的问题属于“能力拼装”还是“身份继承”。
接口：专注行为契约与跨类型能力复用
接口不提供实现，只声明“必须能做什么”。它天然适合定义通用能力，让无关类获得一致操作入口。
- 多个不相关的类需要统一调用方式时，用接口。比如 IDisposable 被 FileStream、MemoryStream、DbContext 等完全不同的类型实现，但上层代码只需调用
Dispose()，无需知道背后是什么。 - 依赖注入和服务替换场景下，接口是首选。IEmailService、ICacheService 这类契约，让业务逻辑不绑定具体实现，测试时可轻松换 Stub 或 Mock。
- 一个类需同时承担多种角色，比如“可保存 + 可验证 + 可日志记录”，只能靠实现多个接口达成，因为 C# 不支持类的多继承。
抽象类：承载身份共性与纵向逻辑复用
抽象类代表“是一类东西”，它把子类共有的字段、构造逻辑、默认方法甚至模板流程封装起来，避免重复编码。
- 当多个子类有大量相同实现（如通用日志、参数校验、初始化步骤），把这些代码放进抽象基类的非抽象方法里，子类直接继承使用，不用每处 copy-paste。
- 需要控制对象创建或销毁生命周期时，抽象类更合适。它可定义带参数的构造函数来强制初始化状态，也可含析构逻辑（虽然推荐用 Dispose 模式），接口做不到这点。
- 模板方法模式典型场景：父类定义算法骨架（如
Execute()），调用几个 abstract 步骤（Validate()、Process()、Save()），子类只实现细节，主流程复用不变。
真实项目中更常见的组合用法
不是非此即彼，而是分层协作。现代 C# 架构普遍采用“接口定义契约 + 抽象类提供默认实现”的双层结构。
- 先定义 ILogger 接口，明确“能记录信息”这一能力；再提供 AbstractLogger 类，封装通用格式化、时间戳、异步写入等逻辑；最终 ConcreteFileLogger 或 ConsoleLogger 继承它并补全文件路径或控制台输出细节。
- ASP.NET Core 中的 ControllerBase 是抽象类，封装了 ModelState、ViewData、Json() 等通用 Web 行为；而它本身又实现了 IActionResultExecutor 等接口，便于框架统一调度。
一句话判断依据
问自己：这个设计是为了让不同类“都能做某事”，还是为了让相似类“少写重复代码”？前者选接口，后者选抽象类；两者都要，就先接口再抽象类。
