核心概念：容器、Bean、DI、AOP 词汇

全章用一个贯穿的场景来钉概念：一个下单服务 OrderService，依赖一个支付网关 PaymentGateway 和一个库存仓储 InventoryRepository。每个概念都回到这个场景，看它在装配这三者时扮演什么角色。

1.1IoC / 控制反转：反转了"获得依赖"的控制权

IoC：对象不再自己创建和查找依赖，而是被动接受外部（容器）塞进来的依赖。

底层机制（比文档深一层）：「反转」反转的是获得依赖的控制权——从"对象主动 new 或主动查找"反转成"容器在启动时通过反射造好实例、再把依赖推送进来"。依赖注入（DI）是这个反转的具体落地手段。所以一句被反复问到的面试题——"IoC 和 DI 是不是一回事"——答案是：同一件事的两个视角。IoC 是"控制权反转"这个结果，DI 是"靠注入来实现反转"这个手段。代价也实打实：启动期要反射扫描和实例化、运行期多一层间接、异常栈里会冒出容器和代理的类名。

场景走查：装配 OrderService 的两种世界

// OrderService 被迫知道"怎么造"它的每一个依赖
public class OrderService {
    private final PaymentGateway gateway;
    private final InventoryRepository inventory;

    public OrderService() {
        // 自己 new：换实现要改这里，依赖的依赖也得自己拼
        this.gateway   = new StripeGateway(new HttpClient(), "sk_live_xxx");
        this.inventory = new MySqlInventoryRepository(new DataSource("jdbc:..."));
    }
}

@Service
public class OrderService {
    private final PaymentGateway gateway;
    private final InventoryRepository inventory;

    // 只声明"我需要这两样"，怎么造、用哪个实现，交给容器
    public OrderService(PaymentGateway gateway, InventoryRepository inventory) {
        this.gateway   = gateway;
        this.inventory = inventory;
    }
}

逐步对照（代码 → 概念）：

• 第一段构造器里的 new StripeGateway(...)：OrderService 掌握"获得依赖"的控制权——这是没有反转的世界。
• 第二段构造器只接收 PaymentGateway 参数、不关心怎么来：控制权已反转给容器。这一步就是 DI（具体说是构造器注入，1.4 节细讲）。
• @Service 是一个声明："把这个类登记成一个 bean，纳入容器管理"——下一节讲 bean。

与下一个概念的关系：容器要"把依赖推进来"，前提是它得先知道有哪些对象要管、各自怎么造。这份"清单 + 配方"就是 bean 与 BeanDefinition。

1.2Bean 与 BeanDefinition：实例 vs 配方

Bean 是容器管理的对象实例；BeanDefinition 是描述"如何造这个 bean"的元数据配方。

底层机制（比文档深一层）：BeanDefinition 是一个可被修改的对象，登记在 BeanFactory 内部的一张 map 里（beanDefinitionMap）。容器启动时分两段走：先把所有 BeanDefinition 收齐（解析 @Component 扫描、@Bean 方法、XML），这时一个 bean 实例都还没造；之后才按配方逐个实例化。正因为有这个"配方先就位、实例后创建"的间隙，才有了 02 章的关键扩展点——在实例化前批量改写配方（占位符替换、@Configuration 解析都在这里发生）。

与下一个概念的关系：这些 BeanDefinition 收在哪、bean 实例缓存在哪？答案是容器本身。但"容器"有两个层次的接口，分界很重要。

1.3BeanFactory vs ApplicationContext：惰性内核 vs 急切全家桶

BeanFactory 是容器的最小内核（惰性按需造 bean）；ApplicationContext 是它的超集，启动时急切造好所有单例并附带企业级能力。

底层机制（比文档深一层）：ApplicationContext 在接口上 extends BeanFactory，实现上内部组合了一个 DefaultListableBeanFactory 来做真正的 bean 管理，自己在外面加了事件多播、消息源、资源加载，以及关键的一条——自动探测并注册容器里所有的 BeanPostProcessor 和 BeanFactoryPostProcessor（裸用 BeanFactory 这些得手动注册）。还有一个常被忽略的硬区别：BeanFactory.getBean 是惰性的，用到时才造；而 ApplicationContext 在启动的 refresh() 末尾会急切实例化所有非 lazy 单例。这条决定了一件事——配置错误在启动期就炸，而不是等到第一次请求才炸，这对线上服务是好事。

与下一个概念的关系：容器把依赖"推进" bean 的动作，落到代码上有三种写法，它们的差别不只是风格——而是注入发生的时机不同。

1.4依赖注入的三种方式：构造器 / setter / 字段

同一个依赖可以从构造器参数、setter 方法、或直接打在字段上注入——区别在注入发生的时机和带来的约束。

底层机制（比文档深一层）：时机是分水岭。构造器注入在容器调用构造器创建实例那一刻就必须把依赖准备好——没有依赖，对象根本造不出来。setter / 字段注入发生在"实例已经造出来之后"的属性填充阶段。这个时机差，直接导致 02 章的一个硬结论：构造器注入的循环依赖无解（A 的构造需要 B、B 的构造需要 A，谁都先造不出来），而 setter/字段注入的循环依赖能靠三级缓存绕开。字段注入还有个隐藏代价：依赖被藏在类内部，不 new 不暴露，使得单元测试必须靠反射或容器才能塞进 mock。

// ① 构造器注入：创建实例时就要依赖；可用 final，依赖必填、可测
@Service
public class OrderService {
    private final PaymentGateway gateway;
    public OrderService(PaymentGateway gateway) { this.gateway = gateway; }
}

// ② setter 注入：实例造好后调用 setter 填入；适合可选 / 可重配的依赖
@Service
public class OrderService {
    private PaymentGateway gateway;
    @Autowired public void setGateway(PaymentGateway g) { this.gateway = g; }
}

// ③ 字段注入：实例造好后用反射直接写字段；最省字，但最难测、最易藏循环依赖
@Service
public class OrderService {
    @Autowired private PaymentGateway gateway;
}

官方与社区现在的默认推荐是构造器注入：依赖必填、对象可做成不可变、不依赖容器就能 new 出来测试，而且循环依赖会在启动期就暴露成错误，而不是潜伏到运行期变成一个诡异的 null。三者的完整权衡对比放在 03 章，那里有判别表。

与下一个概念的关系：注入进来的依赖，是每次都新造一个，还是全局共享一个？这由 bean 的作用域决定。

1.5Bean 作用域：singleton 与 prototype

作用域决定容器为一个 BeanDefinition 造几个实例、活多久：singleton 全局一个，prototype 每次取都新造。

底层机制（比文档深一层）：singleton（默认）在容器里只造一次，造好缓存在 singletonObjects 这张 map 里，之后每次 getBean 都返回同一个引用，销毁由容器管。prototype 每次 getBean 都走一遍创建流程返回新实例，而且容器造完就撒手——不缓存、不负责调用它的销毁方法。深一层的陷阱在这：把一个 prototype 注入到一个 singleton 的字段里，注入只发生在 singleton 创建的那一次，于是这个 prototype 实际上被"焊死"成了单例，它"每次都新建"的承诺在这种注入下静默失效。web 环境还有 request / session 等作用域，本质是"绑定到某个上下文生命周期"的扩展。

与下一个概念的关系：以上都是"容器怎么管对象"。还有一类需求是"在不改对象代码的前提下，给一批方法统一加行为（日志、事务、限流）"——这是 AOP 要解决的，它有自己的一套词汇。

1.6AOP 术语：切面、切点、通知、连接点、织入、代理

AOP 把"散落在很多方法里的横切逻辑"（日志、事务）抽出来集中定义，再在运行期织入目标方法周围。

六个术语必须一次对齐，后面 03 章直接用：

底层机制（比文档深一层）：注意表里加粗的两条 Spring 特有约束。第一，Spring 的连接点只有"方法执行"——它不像完整的 AspectJ 那样能拦字段读写、构造器调用。第二，织入发生在运行期，靠生成一个代理对象完成：容器把通知逻辑包进一个代理，外部对目标方法的调用先经过代理、再转给原对象。这两条合起来推出一个 03 章的核心结论——既然增强只在"从外部经过代理引用"的调用上生效，那么对象内部的 this.method() 自调用走的是原始引用、绕过了代理，通知不触发。@Transactional 在同类自调用下静默失效，根因就在这里。