SOLID原则是达成高内聚、低耦合的手段，核心在于按变化原因划分职责（SRP）、依赖抽象而非实现（DIP、OCP、LSP）、按角色提供精简接口（ISP），并作为重构指南而非编码教条。
遵循SOLID原则本身不是目的，而是达成高内聚、低耦合的手段。关键不在于机械套用五条规则，而在于理解每条原则背后对“职责”和“依赖”的处理逻辑——让类只做一件事且做好，让模块之间通过抽象而非具体细节关联。
单一职责原则（SRP）：一个类只负责一个变化原因内聚性的核心是“聚焦”。当一个类同时处理用户验证、日志记录和数据库保存时，三者任一需求变动都可能迫使你修改这个类，导致意外影响。真正的单一职责，是按“变化原因”划分，而非功能数量。
识别变化点：比如“登录策略调整”“审计要求升级”“数据库从MySQL迁移到PostgreSQL”，它们是不同维度的变更驱动把每个变化原因封装成独立类：Authenticator、AuditLogger、UserRepository避免“工具类”陷阱：Utils、Helper这类命名往往是职责模糊的信号，应替换成有明确业务语义的类名开闭原则（OCP）与里氏替换原则（LSP）：用多态隔离变化，确保可替换性低耦合的关键是“依赖抽象”。当高层模块直接调用具体实现（如new MySQLUserRepo()），它就和MySQL强绑定。OCP要求对扩展开放、对修改关闭；LSP确保子类能无缝替代父类——二者共同支撑起可插拔的设计。
定义接口或抽象类描述行为契约：interface UserRepository { User findById(String id); void save(User u); }具体实现类只依赖该契约，不暴露内部技术细节（如JDBC连接、SQL语句）
子类重写方法时，不改变原方法的前置条件（输入范围）、后置条件（输出保证）和不变量（如“save后id必不为空”）
依赖倒置原则（DIP）：让高层模块不依赖底层模块，都依赖抽象这是实现松耦合最直接的操作指南。它不是说“不要依赖”，而是“不要依赖具体实现”。依赖关系必须指向稳定、抽象的契约，而非易变的细节。
避免在Service类中直接new Repository实现类；改用构造函数注入或setter注入抽象类型抽象不应由实现类决定，而应由使用方（如Service）提出需求，再由基础设施层提供适配实现一个典型反例：Controller里写new HttpClient()——它本该依赖IHttpClient，由配置决定用OkHttp还是RestTemplate接口隔离原则（ISP）：按角色提供精简接口，避免臃肿契约大而全的接口（如包含15个方法的IEntityService）会迫使实现类承担无关职责，也导致调用方依赖未使用的部分，增加隐式耦合。ISP强调“客户驱动的接口”，谁用、怎么用，就定义什么。
按调用场景拆分：IUserReader、IUserWriter、IUserAdmin，而非一个IUserService接口中方法应具有强语义相关性：比如findById和findAll可以共存，但findById和sendEmail就不该出现在同一接口允许一个类实现多个小接口，比强迫它实现一个大接口更灵活、更安全不复杂但容易忽略的是：SOLID不是编码前的蓝图，而是重构时的指南针。先写出清晰表达意图的代码，再用SOLID检查哪里出现了重复修改、难以测试或牵一发而动全身的情况——那里就是内聚不足或耦合过高的信号。