1. 从new说起为什么Spring IoC值得花一章来学我相信每个刚接触Java后端的人都有过类似的体验读官方文档看到控制反转Inversion of Control依赖注入Dependency Injection这两个概念字面意思都认识但完全不知道代码上要怎么写、为什么要这么写。跟着教程敲了一遍又一遍容器倒是跑起来了可心里总觉得不踏实——这玩意到底好玩在哪我把话放在前面Spring IoC的意义不在于换一种方式创建对象而在于把对象之间的组装关系从代码里抽离出去放到一个统一的地方去管理。这一章讲的是入门案例但我会把背后的设计逻辑、常见误区和排查思路一起讲透。学完以后你再去看AOP、事务管理这些内容会发现它们全都建立在这套装配合约之上。这一章适合三类人来看第一次接触Spring、想通过一个最小案例建立体感的学习者写过一些Spring但只会照抄配置、遇到bean相关报错就懵的初学者以及准备面试、想把IoC概念讲清楚而不是背定义的求职者。先说最朴素的问题假如没有IoC一段业务代码长什么样public class UserService { private UserDao userDao new UserDao(); public User getUserById(Long id) { return userDao.findById(id); } }这段代码看起来干干净净问题出在哪里问题在于UserService这个类自己决定了要创建哪个UserDao。假如明天UserDao的实现类变了或者要在测试时换成mock对象你就得打开UserService源码去改这一行——而如果项目里有一百个地方都用new UserDao()那就是一百处改动。我见过最夸张的一次一个老项目里DateFormat这类工具对象被new了几百次后来升级接口签名全局翻代码翻到崩溃。这个痛点就是IoC要解决的第一个核心问题。IoC做的事情用一句话说清楚对象自己不再负责创建依赖而是声明我需要什么由容器在合适的时机把依赖交到它手里。创建对象的控制权从对象自己转交到容器——这是控制反转。容器把依赖对象注入到当前对象的过程——这是依赖注入。这样一拆你就能明白为什么很多高手会把IoC和DI放在一起讲IoC是设计思想谁说了算DI是具体实现技术怎么给到。给你打个比方。以前做饭从买菜、洗菜、切菜到炒菜全是自己干这叫主动依赖现在点外卖你只管在App上告诉平台想吃什么饭送到你手上——至于哪个厨师做的、在哪做的、怎么做熟的你一概不需要也没资格干涉。这就是控制反转你自己不造依赖了转而声明依赖。那容器又是从哪里冒出来的下面我们进入工具层面。2. 两个核心接口容器从哪里来bean又是什么Spring容器不是玄学它是一个实实在在的对象池。所有被容器管理的对象都叫bean。这章的案例里你会看到容器、bean、配置文件三者之间的关系可以用一句话先记住配置文件是说明书容器是照说明书干活的生产线bean是生产线上造出来的零部件。2.1 BeanFactory与ApplicationContext先认识两个大管家Spring的容器有两个核心接口面试也常考捋清楚它们的关系很重要接口定位特点BeanFactory最底层的容器接口懒加载调用getBean时才会实例化对象ApplicationContext增强版容器继承BeanFactory启动时预加载单例bean附加事件发布、国际化、资源加载等能力我在入门案例里直接推荐ApplicationContext不在乎那点性能差异。原因很简单工程中几乎没有直接拿BeanFactory用的场景而且它的懒加载行为会给新手造成怎么没报错到底创建了没有的虚假安全感。ApplicationContext常用实现类有这些认识一下即可ClassPathXmlApplicationContext从类路径加载XML配置文件FileSystemXmlApplicationContext从文件系统加载XMLAnnotationConfigApplicationContext基于注解/JavaConfig的容器入门阶段用ClassPathXmlApplicationContext最直观配置文件放resources目录下一行代码就能把容器启动起来。2.2 三种配置方式为什么先从XML学起配置bean有三大流派XML配置、注解配置、JavaConfig配置。我建议案例阶段一定要从XML入手。别急着用ComponentXML的好处是所见即所得——容器里有哪些bean、每个bean的依赖是什么全在一份文件里摊开一目了然。注解在IDE里是散落的你必须自己脑补哪些类被扫描到了对概念尚未建立的初学者来说很容易产生理解偏差。打个比方XML让你先看仓库库存清单注解则是你需要在货架上一个一个找。等这套装配逻辑在脑子里扎根了再切换到注解你就知道Autowired背后其实还是在走容器找bean、按类型匹配、注入那套流程。下面的入门案例就是用XML方式来演示的。3. 手写第一个IoC案例一份能跑通的最小工程案例题目很常见通过Spring IoC容器获取用户信息。我不绕弯子直接用一个最贴近真实开发形态的例子把CURD的架子搭起来重点看容器如何把UserDao装配进UserService。3.1 项目结构与Maven依赖Maven工程结构如下src └── main ├── java │ └── com.demo │ ├── dao │ │ ├── UserDao.java │ │ └── impl │ │ └── UserDaoImpl.java │ ├── service │ │ ├── UserService.java │ │ └── impl │ │ └── UserServiceImpl.java │ └── Main.java └── resources └── applicationContext.xml新建一个普通的Maven项目不需要Spring Bootpom.xml里加上dependencies dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version5.3.31/version /dependency /dependencies为什么只需要spring-context一个坐标因为它是Spring容器的核心包会把spring-core、spring-beans、spring-aop等基础依赖自动带进来。这个版本的选取我用了5.3.x稳定且兼容性广如果你跟的是较新的Spring 6.x或者直接上的Spring Boot 3.x依赖坐标不变但要注意JDK版本需要17以上。这里先用5.3.x是因为它兼容JDK 8对新手环境最友好。提示下载依赖慢是网络问题不是配置问题调整Maven镜像源解决。不要纠结于为什么我加了依赖还报ClassNotFoundException——先确认spring-core是否真的进入了本地仓库。3.2 接口与实现类解耦从面向接口开始按照真实项目的习惯DAO和Service都拆成接口实现类。先定义DAO层package com.demo.dao; public interface UserDao { String getUserNameById(Long id); }package com.demo.dao.impl; import com.demo.dao.UserDao; public class UserDaoImpl implements UserDao { Override public String getUserNameById(Long id) { // 模拟从数据库查询 return 用户- id; } }接下来是Service层。这是本案例的灵魂实现类里不出现new UserDaoImpl()而是声明一个UserDao字段并提供setter方法——这个setter专门用于接收容器注入package com.demo.service; public interface UserService { String getUserName(Long id); }package com.demo.service.impl; import com.demo.dao.UserDao; public class UserServiceImpl implements UserService { private UserDao userDao; // setter注入容器会通过这个方法把UserDaoImpl传进来 public void setUserDao(UserDao userDao) { this.userDao userDao; } Override public String getUserName(Long id) { return userDao.getUserNameById(id); } }你可能会问为什么搞个setter直接给字段不行吗用setter是历史遗留也是最容易理解的注入方式它明确暴露了容器将要调用这个方法来设置依赖。后续切到注解开发Autowired会在字段上直接注入但底层缺省还是要走Setter/构造器。现在先不贪多把setter注入吃透就够。3.3 配置文件bean的户口簿在src/main/resources下新建applicationContext.xml?xml version1.0 encodingUTF-8? beans xmlnshttp://www.springframework.org/schema/beans xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd bean iduserDao classcom.demo.dao.impl.UserDaoImpl/ bean iduserService classcom.demo.service.impl.UserServiceImpl property nameuserDao refuserDao/ /bean /beans解读一下这份户口簿第一个bean标签表示容器帮我创建UserDaoImpl对象id叫userDao。第二个bean标签表示容器帮我创建UserServiceImpl对象id叫userService。property nameuserDao refuserDao/表示创建userService这个bean时调用setUserDao方法传入id为userDao的那个bean。nameuserDao对应的是setter方法名的定位——setUserDao去掉set、首字母小写就是userDao。这个规则在很多框架里都通用理解了以后看别人的配置就不会发懵。3.4 启动容器见证装配结果写一个最简单的入口来运行package com.demo; import com.demo.service.UserService; import org.springframework.context.support.ClassPathXmlApplicationContext; public class Main { public static void main(String[] args) { // 1. 加载配置文件启动容器 ClassPathXmlApplicationContext context new ClassPathXmlApplicationContext(applicationContext.xml); // 2. 从容器中获取bean UserService userService (UserService) context.getBean(userService); // 3. 调用业务方法 String name userService.getUserName(1L); System.out.println(查询结果 name); // 4. 关闭容器 context.close(); } }运行结果查询结果用户-1但你现在应该想到一个问题UserService的实现类里明明没有new过UserDaoImpl为什么userService.getUserName(1L)能用userDao答案就在配置文件那一行property——容器在创建userService时已经提前把userDaobean塞进去了。这就是所谓的依赖注入第一次在你眼前显形。4. getBean的四种姿势用容器取bean信息的实用指南第一遍跑通之后大部分人会卡在同一个地方getBean这个API到底怎么用才对标题里那句使用spring ioc 容器获取bean信息就落在这一节。我结合踩过的坑把常见写法从头到尾过一遍。4.1 按id获取最原始但最不推荐UserService userService (UserService) context.getBean(userService);这种方法我前面用了但从工程视角来说不可取。原因有三字符串写错不报编译错要等运行时才炸类型转换出错是隐蔽的编译器完全不管没有任何代码提示全靠人肉记忆。所以它能用来做演示但别养成习惯。4.2 按类型获取类型安全但怕一型多beanUserService userService context.getBean(UserService.class);这是类型安全的不需要强制转换IDE还能跳转查看定义。但它有个前提**在容器中这个类型只能对应唯一一个bean。**一旦你定义了两个UserService类型的bean比如bean iduserServiceA classcom.demo.service.impl.UserServiceImpl/ bean iduserServiceB classcom.demo.service.impl.UserServiceImpl/再执行上面的代码Spring会直接抛出NoUniqueBeanDefinitionExceptionexpected single matching bean but found 2: [userServiceA, userServiceB]遇到这个问题要么改用getBean(userServiceA, UserService.class)精确指定要么用Primary标记首选bean——这是后话但你要知道按类型的核心矛盾在这里。4.3 按名称类型联合获取最稳妥的姿势UserService userService context.getBean(userService, UserService.class);这个方法同时校验id和类型既避免了字符串风格的类型转换隐患又解决了多bean的歧义问题。我的建议是**凡是bean的id能够确定就用这种方式。**它是现实开发中最常见的写法之一也最容易读代码的人理解你拿的是哪一个bean。4.4 容器还提供了一组体检方法查有没有、查是什么、查所有getBean是拿对象但实际排查问题的时候你更需要看容器里有什么。ApplicationContext准确说是ListableBeanFactory接口有一系列方法入门时容易被忽略但排错时特别有用boolean hasUserDao context.containsBean(userDao); System.out.println(是否包含userDao hasUserDao); boolean isSingleton context.isSingleton(userService); System.out.println(userService是否单例 isSingleton); String[] beanNames context.getBeanDefinitionNames(); System.out.println(容器中的bean名称); for (String name : beanNames) { System.out.println(name - context.getType(name)); }这里面getBeanDefinitionNames是排查我的bean怎么没创建的常用工具——它会把当前容器里定义的所有bean名打印出来。如果你发现自己配了却没打印出来问题大概率出在配置文件没被加载或者id写错了。另外context.getType(bean的名称)可以快速确认某个bean的真实类型跟你预期是否一致处理类型转换问题的时候特别香。我还想提醒你一个细节context.getBean(userService)第一次调用时如果是ApplicationContext而不是原生的BeanFactory那么在容器启动阶段bean已经被实例化好了getBean只是取货。所以入门阶段开局加载慢一点别焦虑。5. 入门必踩的五个坑从报错堆栈读到问题根因IoC入门案例的代码量很小但这不意味着不会出错。我把过去见到的初学者错误做了一个汇总用一个现象—原因—解决的框架来呈现。你以后不看这篇也能按着这套思路排查。5.1 NoSuchBeanDefinitionException容器里根本没有这个bean现象No bean named userService is defined排查链路从这三步里找答案检查getBean里的字符串是否和XML中bean标签的id完全一致。大小写往往是最容易翻车的地方userService和userService看着像程序可不认。检查配置文件有没有用对。如果applicationContext.xml没有放在resources下或者ClassPathXmlApplicationContext(applicationContext.xml)路径写错容器加载的就是另一个空配置文件。看target/classes目录里是否存在这个XML。Maven项目里如果配置文件不在resources下而是落在src/main/java里有时不会被打进classpath——这属于Maven打包的经典坑复制过去也只会让你看起来有文件实际加载不了。我建议排查时先写一行Arrays.toString(context.getBeanDefinitionNames())看输出比起盲猜快得多。5.2 NullPointerException注入没产生service拿到空指针这是最让人摸不着头脑的报错之一Exception in thread main java.lang.NullPointerException at com.demo.service.impl.UserServiceImpl.getUserName(UserServiceImpl.java:18)NPE的位置在userDao.getUserNameById(id)这行说明userDao字段是null。通常原因只有一个XML的property没配对。bean iduserService classcom.demo.service.impl.UserServiceImpl property nameuserDao refuserDao/ !-- 如果name写错注入被忽略 -- /beanproperty的name必须对应setter方法名去掉set后首字母小写的形式。写错以后Spring不报错只是不执行注入让你在运行时才开始痛苦。这也是我建议入门阶段所有依赖都走setter的原因——一旦出错你能立刻在XML上看出来。5.3 ClassNotFoundException或ClassCastExceptionclass配置错了如果是ClassNotFoundException说明bean标签的class属性写错了全限定名比如漏写了包名或者包结构调整后XML没有同步更新。如果是ClassCastException更多是按类型转换时用错了类型比如UserService userService (UserService) context.getBean(userDao);id指向的是UserDao的bean你却把它当成UserService来转换——这种低级错误前面说过的getBean(id, 类型)联合方式能帮你提前拦住一半另一半靠看id别靠猜的习惯。5.4 BeanDefinitionStoreExceptionXML格式或文件路径有问题这个异常多半在容器启动阶段就抛出来。看到BeanDefinitionStoreException先做以下三件事用IDE打开XML看有没有明显语法错误比如标签没闭合。看xsi:schemaLocation写对了没有空格和换行不要乱来。确认文件确实能被类路径加载——最稳妥的做法是把XML放到resources根目录而不是子目录里绕一圈再把路径写错。5.5 NoUniqueBeanDefinitionException按类型取bean遇到一型多bean前面已经提到过这个异常的场景很典型同一种类型有多个bean你却用了getBean(UserService.class)。这时候有两个解决思路改getBean(具体id, UserService.class)精确锁定在多个bean中用primarytrue标记其中一个为主beanbean iduserServiceA classcom.demo.service.impl.UserServiceImpl primarytrue/ bean iduserServiceB classcom.demo.service.impl.UserServiceImpl/这样getBean(UserService.class)就能成功Spring会默认给你primary的那个。注意多个bean同时标记primarytrue是没有意义的Spring会继续抛异常因为你给了它两个首选。这种问题在注解配置里同样存在记住一个原则——首选只能有一个。6. 案例之外IoC之后你还需要掌握的三件事案例跑通了报错会排查了接下来如果想让IoC这块基础更扎实还有三件事值得在上手第一周内做掉。6.1 bean的作用域单例还是原型默认情况下所有bean都是单例的——容器只创建一次后续getBean拿到的都是同一个对象。这一点可以在代码里快速验证UserService s1 context.getBean(userService, UserService.class); UserService s2 context.getBean(userService, UserService.class); System.out.println(s1 s2); // true说明是同一个对象若需要每次获取都得到新实例就在bean标签上加scopeprototype。但现实中业务Service基本都用单例因为Service本身无状态、依赖的DAO也是线程安全的单例省内存且效率高。你只需要知道prototype的存在具体什么时候用——比如多例状态对象、原型模式的场景——那是后面设计层面的事。6.2 构造器注入与setter注入选谁我示例里用了setter注入因为理解门槛最低。但在实际项目中我更推荐构造器注入public class UserServiceImpl implements UserService { private final UserDao userDao; public UserServiceImpl(UserDao userDao) { this.userDao userDao; } // ... }配合XMLbean iduserService classcom.demo.service.impl.UserServiceImpl constructor-arg refuserDao/ /bean理由也很务实字段用final修饰保证依赖一旦注入不可变、也不会出现忘了setter导致NPE的尴尬同时在编译期就能发现谁缺构造参数。代价是代码行数稍微多点需要你多写一个构造方法。如果你参考的开源代码用的是构造器注入不用觉得奇怪——这是成熟的工程惯例。6.3 注解驱动到底是接着学还是马上学我的建议是把XML案例吃透后再切注解但不要拖太久。切的时候你只需要关注三个注解Component标记类为beanAutowired按类型自动注入依赖ComponentScan告诉容器去哪里扫描带注解的类用起来是这样的Component public class UserDaoImpl implements UserDao { // ... } Component public class UserServiceImpl implements UserService { Autowired private UserDao userDao; // ... }然后XML就可以缩成一行扫描配置context:component-scan base-packagecom.demo/或者干脆不要XML换成AnnotationConfigApplicationContext加一个配置类。你会发现注解背后做的事情跟XML一模一样只不过户口簿从文件变成了一大堆注解。这个转变在概念上并没有新增负担因为容器那套逻辑你已经通透了。以我自己的学习路径来看最早写的那个Hello World式的IoC案例在之后理解Spring Boot的自动装配、MyBatis的mapper扫描乃至微服务里的各种starter原理时都发挥了重要支撑作用。说句掏心窝的话Spring这个框架最值得花心思的就是容器这套机制。你现在跑通的不只是一个案例而是后续所有框架特性的地基。建议你把文中的代码自己完整敲一遍再故意改错几个地方比如把id写错、把name写错用报错回答自己的好奇——这样踩出来的经验比任何教程里的注意都管用。