呱呱 研发协作
Spring Boot 依赖注入：用构造器优先…
在创建 Spring Boot 服务/配置类、替换字段注入或排查 Bean 歧义与上下文启动失败时，用构造器注入和显式装配策略组织依赖。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 49/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
Spring Boot 依赖注入：用构造通用
解决思路
- 对每个类区分必需协作者与可选协作者：必需协作者放入构造器，可选协作者使用 ObjectProvider、条件 Bean 或 no-op 实现等显式策略。
- 默认使用构造器注入：必需依赖通过构造器注入，注入字段保持 final，单元测试中直接实例化类而不启动 Spring；只有一个构造器时无需 @Autowired。
- 有意识地处理可选行为：需要延迟访问时用 ObjectProvider<T>；装配随配置变化时用 @ConditionalOnProperty 或 @ConditionalOnMissingBean；调用方不关心功能是否启用时用 no-op 实现；避免可空协作者导致运行时行为不明确。
- 仅在需要时使用 Bean 选择注解：同类型多个 Bean 时，用 @Primary 指定默认实现，用 @Qualifier 指定命名变体，并保持限定符名称稳定且易于 grep；选择规则复杂时移入专用配置类，不要分散在服务中。
- 把装配逻辑放在配置中而非业务代码：对象来自第三方库、需要条件创建逻辑、需要环境相关装配或显式组合时，使用 @Configuration 和 @Bean 方法；业务服务不应知道基础设施协作者如何实例化。
- 显式验证装配：先用最小上下文测试验证 Bean 能加载（如 @SpringBootTest + @ContextConfiguration(classes = UserService.class) 并断言非空）；再运行业务行为的构造器单元测试（无需 Spring）；仅在需要验证 MVC、JPA 或消息集成时添加切片测试；把 @SpringBootTest 保留给容器级装配验证；第 1 步失败说明在加入业务逻辑前就存在装配问题。
- 保持服务构造器精简：如果类需要过多协作者，通常说明设计上还需要再抽象一层。
- 重构时移除字段注入，而不是继续扩展它。
- 循环依赖通常是设计问题，不要用 @Lazy 当作装配技巧来解决。
- 避免过度使用限定符；优先更好的抽象或更清晰的配置。
- 可选协作者在缺失时仍需有确定行为。
- 不要过早使用全上下文测试，否则可能掩盖装配失败的真正来源。
适用边界 · 注意事项
- 字段注入会隐藏依赖并让测试更难编写，应避免。
- 循环依赖通常应通过重新设计解决，而不是用 @Lazy 绕过。
- 过度使用 @Qualifier 会让代码难以推理，应优先改进抽象或配置。