IoC 与依赖注入

这一课你将能做到

1. 解释控制反转（IoC）解决什么问题，并把一个 new 出来的依赖改造成容器注入
2. 熟练使用构造器注入，处理多实现冲突（@Primary / @Qualifier）和策略集合注入
3. 诊断并修复 NoSuchBeanDefinitionException、循环依赖这两类高频报错

为什么要学

没有 IoC 时，对象之间的关系是「谁用谁 new」：

public class TaskService {
    private EmailSender emailSender = new EmailSender();   // 自己 new，焊死了
}

问题立刻浮现：想换成短信通知要改源码；EmailSender 自己还依赖别的对象，你得一层层手动构造；写单测时没法把 EmailSender 换成假的。

IoC（控制反转）：把「创建对象、组装依赖」的控制权，从你的代码反转给 Spring 容器。你只声明「我需要一个 EmailSender」，容器造好后**注入（DI）**给你。对象之间从「硬编码焊接」变成「接口插拔」，这正是分层架构能解耦的基础。本站后端的 Service 层依赖 Repository、Controller 依赖 Service，全部走容器注入。

先建立图像

        你写代码时                    容器启动时
   ┌─────────────────┐          ┌──────────────────────────┐
   │ TaskService      │          │ 扫描 @Component/@Service  │
   │  "我要一个       │   ──→    │ 发现 NotificationSender   │
   │  Notification-   │          │ 有两个实现 → 决定用哪个    │
   │  Sender"         │          │ new 好它们，再 new         │
   └─────────────────┘          │ TaskService 并把依赖塞进去 │
                                └──────────────────────────┘

名词	人话
IoC 容器	Spring 的「对象工厂 + 仓库」，负责创建、组装、管理所有 Bean
Bean	被容器管理的对象（默认全局一个实例）
依赖注入（DI）	容器把依赖「塞」给 Bean 的动作，是 IoC 的实现手段
@ComponentScan	启动时的「搜捕行动」，把标注了 stereotype 注解的类登记进容器

跟着做

步骤 1：先感受「new」的痛

// 痛点演示：业务代码硬编码依赖实现
public class TaskService {
    // 想换 SmsSender？只能改这一行源码，重新编译。
    // 写单测想 mock 掉发邮件？没办法，它是在构造时 new 死的。
    private final EmailSender emailSender = new EmailSender();
}

先定义接口和两个实现，作为本课的领域模型：

package com.example.taskflow.notify;

public interface NotificationSender {
    String channel();
    void send(String to, String content);
}

package com.example.taskflow.notify;

import org.springframework.stereotype.Component;

@Component                      // 登记进容器
public class EmailSender implements NotificationSender {
    @Override
    public String channel() { return "email"; }

    @Override
    public void send(String to, String content) {
        System.out.println("[邮件] 发给 " + to + "：" + content);
    }
}