SOLID不是银弹，而是针对“改一处崩一片”的五条反思性约束；它不规定写法，只警示频繁修改多类多方法即可能违反原则。
什么是SOLID，它真能帮你少改代码？
不能。SOLID 不是银弹，也不是检查清单；它是五条事后被归纳出来的、针对“改一处崩一片”这种 Java 项目常见病的反思性约束。你写完 UserService 后发现加个微信登录就得重写整个认证流程——这时候回看 SingleResponsibilityPrinciple 才有实感。
它不规定你怎么写类，只告诉你：如果每次加新功能都要动三个类、改八个方法、注释掉两段旧逻辑，那大概率已经违反了至少两条原则。
接口隔离原则（ISP）在 Spring Boot 里怎么落地？
很多人以为 ISP 就是“多拆接口”，结果搞出一堆 UserQueryService、UserUpdateService、UserDeleteService，反而让调用方要注入四个 bean。错不在拆，而在没分清「能力契约」和「使用场景」。
- 真正该隔离的是「谁在用」：比如
AdminController需要deleteById()，但AppUserController绝对不该看到这个方法——这时应定义AdminUserOps接口，而非按 CRUD 拆 - Spring 的
@Qualifier和@Primary不是补 ISP 的洞，而是掩盖它；用多了说明接口职责太宽 - 注意
default方法不是万能解药：在UserRepository里塞一个default findActiveByPhone(String)，等于把业务规则泄漏进数据层
依赖倒置（DIP）为什么总在测试时露馅？
现象很典型：单元测试里一 mock HttpClient 就卡住，或者 new ObjectMapper() 出现在 service 方法里，导致无法替换 JSON 序列化行为。这不是测试写得差，是 DIP 没立住。
立即学习“Java免费学习笔记（深入）”；
- 判断依据很简单：你的 service 类里有没有出现
new关键字创建第三方库对象？如果有，就违背了 DIP - Spring 的
@Autowired不等于自动满足 DIP；如果注入的是RestTemplate而非自定义的OrderApiClient，只是把耦合从 new 搬到了注入点 - 容易忽略的坑：
LocalDateTime.now()看似无害，但它隐式依赖系统时钟——正确做法是定义ClockProvider接口并注入，否则所有时间相关逻辑都无法稳定测试
Liskov 替换原则（LSP）在继承体系里最常栽在哪？
Java 里最隐蔽的 LSP 违反，往往藏在 protected 方法和构造器参数里。比如你写了 BaseOrderService，子类 InternationalOrderService 重写了 validate()，却要求父类的 process() 必须先调用 setCurrencyCode()——这已经不是扩展，是强约束。
- 子类不应在父类方法执行前/后插入强制逻辑，尤其不能靠文档约定：“请务必先调用
init()” -
final不是防 LSP 的手段，而是放弃扩展权；真正该做的是把可变部分抽成策略接口，比如把校验逻辑交给OrderValidator实现类 - 泛型擦除会让 LSP 更难察觉：声明
List<string></string>的变量实际接收ArrayList<string></string>没问题，但若某处硬编码了LinkedList特有的getFirst()，就破坏了对 List 接口的替换性
原则本身不复杂，难的是在日志埋点、异常包装、缓存装饰这些“小优化”里守住边界——它们最容易悄悄绕过抽象，把实现细节焊死在调用链里。
