SOLID原则是五条提升代码可维护性的设计准则，包括单一职责（类只做一件事）、开闭（对扩展开放、对修改关闭）、依赖倒置（依赖抽象而非实现）、里氏替换（子类可安全替换父类）和接口隔离（接口应小而专）。
C# 中的 SOLID 原则是五条设计准则，不是语法规范，也不是编译器强制要求——但它直接决定你写的代码能不能轻松加功能、改 Bug、写单元测试，或者交到别人手上时不被骂。
它解决的是“类越写越大、改一处崩三处、新加个支付方式要动七个文件”这类真实痛点。下面说清楚每条怎么用、为什么这么用、以及新手最常踩的坑。
单一职责原则（SRP）：一个类只干一件事，别当瑞士军刀
典型错误是把 Employee 类塞进工资计算、数据库保存、邮件发送、日志记录——改发邮件格式？得打开这个类，顺便 review 一遍数据库连接字符串有没有写错。
正确做法是拆：Employee 只存属性；SalaryCalculator 负责算钱；DatabaseRepository 管增删改；EmailService 发邮件。
- 判断是否违反 SRP：问自己“如果需求变，有几种可能要改这个类？”答案 >1 就该拆
- 别为了拆而拆：比如
CustomerName和CustomerEmail各建一个类，就过了——它们天然属于同一语义边界 - 日志、异常捕获、配置读取这些横切关注点，最容易偷偷混进业务类里，要特别警惕
开闭原则（OCP）：新功能靠“加”，而不是“改”
当你需要支持微信支付，却不得不去改 PaymentProcessor.Process() 方法加 if (type == "WeChat") 分支，就已经违反 OCP。
核心解法是抽象+多态：IPaymentMethod 接口定义 Pay()，让 WeChatPayment、CreditCardPayment 各自实现，PaymentProcessor 只依赖接口，不关心具体类型。
- 抽象粒度很重要：不要一上来就抽象“所有支付”，先从“同步支付”和“异步回调”这种实际差异点开始分
- OCP 不等于“绝不改旧代码”：重构接口、调整参数是允许的；关键是“新增能力不碰已有逻辑”
- 避免过度设计：刚加支付宝，就提前预留 10 个扩展点，反而增加理解成本
依赖倒置原则（DIP）：高层模块不依赖低层模块，都依赖抽象
常见反模式：OrderService 直接 new SqlOrderRepository()，导致单元测试只能连真实数据库，或者换 MongoDB 就得重写全部服务层。
正确姿势：定义 IOrderRepository 接口，OrderService 构造函数接收它；SqlOrderRepository 和 MongoOrderRepository 各自实现——谁创建、谁传入，交给 DI 容器或工厂。
- DIP 是依赖注入（DI）的理论基础，但 DIP ≠ DI：没用 DI 容器，手动传接口也算遵守 DIP
- 接口命名要体现角色，不是技术：用
IEmailSender，别用ISmtpClient - 别把 DTO、Entity 当接口用：它们是数据载体，不是行为契约
里氏替换 & 接口隔离（LSP / ISP）：子类别骗人，接口别贪多
LSP 的本质是“父类能跑通的逻辑，子类不能悄悄绕过”。比如 Rectangle 继承 Shape 没问题，但若 Square 继承 Rectangle 并在 SetWidth 里强制同步 Height，那调用方按矩形逻辑设宽高后，面积就错了——这就是 LSP 破坏。
ISP 针对的是“大而全”的接口：比如 IMachine 同时定义 Print()、Scan()、Fax()，结果打印机实现类得给 Scan() 抛 NotSupportedException。应该拆成 IPrinter、IScanner、IFaxMachine。
- LSP 最容易在“为了复用强行继承”时出事，优先考虑组合（has-a）而非继承（is-a）
- ISP 不是越小越好：一个接口只有 1 个方法，但被 20 个类同时实现，大概率说明职责划分有问题
- 这两个原则常一起暴露：大接口 + 强继承 = 灾难组合
真正难的不是记住这五个字母，而是每次写 class 前，多问一句：“它以后会因为几种不同的原因被修改？”——这个问题的答案，比任何设计模式都管用。
