IoC 的本质是“谁决定对象怎么创建”，即对象的创建时机和依赖来源是否由自身决定；若A类构造函数接收B实例而非直接new B()，则控制权移交，实现反转。
IoC 不是“把控制权交给框架”，而是“谁决定对象怎么创建”
很多人一说控制反转，就想到 Spring 的 @Autowired 或依赖注入容器，以为“框架接管了 new”。其实核心判断只有一条：对象的创建时机和依赖来源，是否由该对象自身决定？如果 A 类里直接 new B()，那 A 控制着 B 的实例化；如果 A 的构造函数接收一个 B 实例（不管是谁传进来的），控制权就移交出去了——这就是反转的实质。
常见错误现象：NullPointerException 在 @Autowired 字段上爆发，但类明明被扫描到了。原因往往是手动 new A()，绕过了容器生命周期，导致注入字段仍是 null。
- 使用场景：单元测试中需替换真实依赖（如用
MockB替代RealB），必须通过构造/设值注入，不能硬编码new - 参数差异：构造注入强制依赖不为空，设值注入允许可选依赖，但容易遗漏初始化
- 性能影响：容器启动时需解析依赖图并实例化，冷启动稍慢；运行时对象创建开销反而更低（复用已有实例）
手写简易 IoC 容器的关键三步
不用 Spring 也能理解 IoC：本质是“注册 → 解析 → 创建”。重点不在功能多，而在明确控制流从哪断开。
常见错误现象：自己写的工厂方法里仍用 if-else 判断类型再 new，只是把 new 搬了个地方，没真正反转。
- 注册：用
Map<Class<?>, Object>存单例，或Map<Class<?>, Class<?>>存类型映射（如put(B.class, MockB.class)） - 解析：递归扫描构造函数参数类型，查注册表，缺哪个就先创建哪个（注意循环依赖：
A依赖B，B又依赖A） - 创建：用
Constructor.newInstance()，别用new—— 这才是把控制权交出去的动作
Spring 中 @Bean 和 @Component 的区别不是“能不能用”，而是“谁在管理生命周期”
@Component 是让 Spring 扫描到后自动注册为 Bean；@Bean 是你在配置类里显式告诉 Spring：“这个对象归你管”。两者最终都进入同一个容器，但入口不同。
常见错误现象：在 @Configuration 类里写 new MyService() 并返回，以为加了 @Bean 就进了容器——错。Spring 只代理 @Bean 方法的调用，不拦截方法体内的 new 行为。
- 使用场景：
@Component适合业务组件（Service、Repository）；@Bean适合第三方类（如RestTemplate、DataSource）或需要复杂初始化逻辑的对象 - 兼容性影响：用
@Bean声明的 Bean 默认是单例，但可以加@Scope("prototype")；@Component同理，但语义上更倾向无状态组件 - 容易踩的坑：在
@Bean方法里调用本类另一个@Bean方法（如service()调用dao()），会绕过代理，导致两次创建——应改为注入Dao字段再用
IoC 的代价：调试时看不到对象从哪来，堆栈里全是 ReflectiveConstructorAccessor
当一个 NullPointerException 出现在某字段上，你得倒推：它是不是被容器注入的？注入源是 @Bean 方法还是 @Component？有没有被 @Profile 过滤掉？这些信息都不在代码行里，而在配置和注解组合中。
最常被忽略的点：IDE 跳转不到注入点。Ctrl+Click myService 字段，看到的是接口或抽象类，实际实现类可能分布在多个模块、多个 @Bean 方法、甚至条件化配置里。这时候得靠 ApplicationContext.getBeanNamesForType(MyService.class) 查到底注册了几个、哪个生效。
