Spring依赖注入本质是将依赖创建权交给容器管理以实现解耦，推荐构造器注入（含final字段、启动校验、易测试），多实现用@Qualifier或@Primary精准定位，强调面向接口编程与配置驱动，避免字段注入以保障可测试性与清晰性。
Spring 的依赖注入（DI）本质是把“谁来创建依赖”这件事，从代码里拿出去，交给容器统一管理。这样组件不再硬编码依赖，也不用关心具体实现类怎么 new 出来，自然就解耦了。
用构造器注入明确依赖边界
这是最推荐的方式，尤其适合不可变、必需的依赖。Spring 在创建 Bean 时，会根据构造函数参数类型自动匹配并注入对应 Bean。
- 声明依赖时直接写 final 字段，强制要求外部提供
- 避免空指针风险——没注入就起不来，问题暴露在启动阶段
- 测试更简单：new 对象时直接传 mock 实例，不用反射或 setter
用 @Autowired + @Qualifier 精准定位多实现
当一个接口有多个实现类（比如 PaymentService 有 Alipay 和 WechatPay），光靠类型无法唯一确定，就需要额外标识。
- @Autowired 按类型匹配，@Qualifier("alipayService") 指定 Bean 名称
- 也可以在实现类上加 @Primary 标记默认首选项
- 避免因扫描顺序或命名模糊导致注入失败或意外交替
用接口编程 + 配置驱动替换行为
真正解耦的关键不在怎么注入，而在依赖什么——依赖抽象（接口），而不是具体类。
立即学习“Java免费学习笔记（深入）”；
- 业务层只面向 UserService 接口编程，不出现 UserServiceImpl 类名
- 不同环境（开发/测试/生产）通过不同配置类或 profile 激活不同实现
- 新增支付方式只需加个新实现类 + 注册为 Bean，无需改调用方代码
避免字段注入，优先考虑可测试性与清晰性
虽然 @Autowired 写在字段上最省事，但它让对象状态不可控、构造不可见，也难做单元测试。
- 字段注入隐藏了依赖关系，阅读代码时看不出哪些东西必须存在
- 无法在测试中跳过 Spring 容器，只能用 @MockBean 或复杂上下文
- 构造器注入配合 Lombok 的 @RequiredArgsConstructor，写法简洁且语义清晰
