依赖倒置原则（DIP）在C#中要求高层与低层模块均依赖抽象，抽象不依赖细节；通过接口/抽象类定义稳定契约，构造函数注入依赖，结合DI容器注册实现，使变化仅限于注册处。
依赖倒置原则（DIP）在 C# 中的核心是：高层模块不依赖低层模块，二者都依赖抽象；抽象不依赖细节，细节依赖抽象。实现的关键不是“不用 new”，而是通过接口/抽象类 + 依赖注入（DI）把具体实现的创建权交给外部。
定义清晰的抽象（接口或抽象类）
先从需求出发，提取稳定不变的行为契约，用 interface 或 abstract class 表达。避免让抽象包含易变的实现细节。
- 比如订单服务需要“发通知”，就定义 INotificationService，而不是直接依赖 EmailSender 或 SmsSender
- 接口方法名要业务语义化（如 SendAsync(Order order)），不暴露技术路径（如不叫 SendEmailBySmtp()）
- 一个接口只聚焦一个职责，符合单一职责，方便后续替换和测试
高层模块通过构造函数接收抽象依赖
业务类（如 OrderService）不自己创建具体对象，而是通过构造函数参数声明它需要什么能力——只认接口，不认实现。
- ✅ 正确写法：public class OrderService(INotificationService notifier)
- ❌ 避免写法：private readonly EmailSender _sender = new EmailSender();（硬编码实现）
- 这样 OrderService 完全不知道也不关心通知是邮件、短信还是钉钉——只要传进来的对象满足 INotificationService 就行
用 DI 容器注册并解析依赖关系
.NET 内置的 IServiceCollection 是最常用方式，在 Program.cs（.NET 6+）中配置绑定规则：
-
services.AddScoped
(); （每次请求新建） -
services.AddSingleton
(); （全局单例） -
services.AddTransient
, OrderValidator>(); （每次使用新建） - 运行时框架自动完成 new 和依赖组装，你只需写好构造函数，其他交给容器
必要时手动传递或工厂模式解耦创建逻辑
当类型无法在启动时确定（比如根据用户选择动态决定通知方式），可引入工厂接口：
- 定义 INotificationFactory，含 CreateFor(User user) 方法
- 工厂内部 new 具体类是允许的——因为工厂本身就是负责“创建”的低层角色，而业务层仍只依赖工厂抽象
- 也可用 Func
或 IServiceProvider（谨慎使用，避免服务定位反模式）
基本上就这些。DIP 不是为抽象而抽象，而是为了让变化点（比如换短信服务商）只改一处注册代码，不碰业务逻辑。写接口、构函注入、容器注册——三步走清，结构就立住了。
