Java设计原则是解决具体问题的实践依据，误用比不用更危险；SOLID需结合变化原因判断拆分，Liskov要求子类不加强前置条件，OCP宜用@ConditionalOnProperty或策略模式，DTO构建优先Lombok@Builder或record，依赖注入按测试需求选构造或字段注入，细节一致性决定系统寿命。
Java设计原则不是抽象教条，而是解决具体问题时反复验证过的判断依据。用错地方比不用更危险。
为什么SOLID五原则在Spring项目里常被误用
很多人把Single Responsibility Principle理解成“一个类只做一件事”，结果写出大量只有两行代码的XXXService、XXXProcessor，反而让调用链路变长、调试困难。关键不在类的行数，而在变化原因是否唯一——比如用户登录逻辑中，密码校验和短信发送如果因不同业务方提出修改要求（安全团队改策略 vs 运营团队换渠道），就该拆；若两者总是一起改，硬拆反而增加耦合。
常见错误现象：NullPointerException频发却归因为“没加@NonNull”，实际是违反Liskov Substitution Principle：子类重写父类方法后改变了前置条件（如父类允许null入参，子类强制非空），导致上游调用崩溃。
- 判断是否真需要拆分，先问：“这个类下次修改，会因为哪类人提需求？他们关注点是否重叠？”
-
Open/Closed Principle在Spring中最自然的落地是@ConditionalOnProperty或策略模式+ApplicationContext.getBean(String, Class)，而非堆砌接口和抽象类 - 避免为“未来可能扩展”提前套用所有原则，等真实变更发生两次再重构更可靠
Builder模式在DTO场景下的陷阱与替代方案
用StringBuilder没问题，但自定义UserDTOBuilder往往得不偿失。当DTO字段超过7个且存在必填/选填混合、字段间有约束（如status=ACTIVE时lastLoginTime不能为空），Builder才真正必要；否则直接用构造函数或Lombok的@Builder（注意启用toBuilder = true）更轻量。
立即学习“Java免费学习笔记（深入）”；
性能影响：每次构建都新建对象实例，高频调用（如日志聚合、消息序列化）时GC压力明显上升。
- 必填字段用构造函数参数，选填字段用
Builder方法——不要所有字段都塞进Builder - 避免在
Builder.build()里做复杂校验（如远程查数据库），这会让DTO失去“数据载体”本质 - 考虑
record（Java 14+）：天然不可变+自动toString/equals，配合静态工厂方法比Builder更简洁
依赖注入时@Autowired与Constructor Injection怎么选
Spring 4.3+规定：类只有一个构造函数时，@Autowired可省略。但这不意味着推荐无注解构造注入——关键看是否需要单元测试时替换依赖。
容易踩的坑：@Resource(name = "xxx")按名称注入时，若Bean名拼错或大小写不符（如声明为userCache却写@Resource(name = "UserCache")），运行时报NoUniqueBeanDefinitionException而非编译错误。
- 必须可测的组件（如Service层）强制用构造注入，保证依赖不为空
- Controller层可用
@Autowired字段注入，因Spring MVC测试框架（MockMvc）对字段注入支持更成熟 - 循环依赖场景下，
Setter Injection是唯一合法解法，但应视为设计缺陷信号，优先重构
public class UserService {
private final UserRepository userRepository;
private final CacheManager cacheManager;
// 显式标注@Autowired，明确表达这是Spring管理的依赖
public UserService(@Autowired UserRepository userRepository,
@Autowired CacheManager cacheManager) {
this.userRepository = userRepository;
this.cacheManager = cacheManager;
}
}
原则本身不难记，难的是在日志打印、异常包装、配置加载这些“不起眼”的环节里保持一致性。比如一个try-catch块里吞掉异常却不打日志，就同时违反了Single Responsibility（处理业务+静默失败）和Dependency Inversion（上层无法感知下层故障）。这类细节，比选什么设计模式更能决定系统寿命。
