我们来用个点外卖的故事把这两个概念讲明白。1. 先看“正常”的做法没有控制反转假设你是个很宅的程序员叫小张。你想吃午饭但你不信任外卖平台决定自己做饭。于是你的代码逻辑是 小张饿了 - 小张自己开火 - 小张自己炒菜 - 小张吃饭。这里的关键是小张掌握一切控制权。他亲自控制“什么时候做饭”、“做什么菜”、“怎么做”。但代价是小张必须依赖具体的厨具、食材。如果今天没电了环境变了小张就吃不上饭还得自己修电。2. 再看“依赖注入”的做法把依赖送进来后来小张想通了决定点外卖。他打开美团下单了一份“黄焖鸡米饭”。这时-依赖小张依赖“饭菜”才能不饿。-注入这份饭菜不是小张自己创造的而是由外卖小哥外部容器主动送进来给他的。用代码思维就是 小张的构造函数里不需要 new 黄焖鸡()只需要声明 我要一份午餐。 外部美团系统会根据订单把做好的饭“注入”到小张手里。这样小张就不用管饭是怎么做的、谁送的。他只要声明需求外部就给他塞进来。3. 什么是“控制反转”IoC继续上面的故事。以前小张控制着做饭的全流程买菜、切菜、开火。现在小张把控制权交出去了——他不再控制“什么时候拿到饭”、“饭从哪里来”。现在控制权在谁手里-美团平台也就是Spring这类IoC容器。- 美团决定什么时候接单、派哪个骑手、几点送达。小张只是被动地接收。这就叫控制反转控制权从“我小张”手里反转到了“容器美团”手里。---4. 它们俩是什么关系一句话总结控制反转IoC是思想依赖注入DI是实现方式。-控制反转就像你说“我懒得管饭怎么来你们安排吧”。-依赖注入就像外卖员真的把饭塞到你手里。这就是实现“我懒得管”的具体做法。5. 用代码类比伪代码没有IoC/DI自己掌控class 小张 { 午餐 我的饭; 小张() { 我的饭 new 黄焖鸡米饭(); // 自己new自己掌控 } }用了DI被注入class 小张 { 午餐 我的饭; 小张(午餐 送来的饭) { // 饭是别人传进来的不是自己new的 我的饭 送来的饭; } }外部容器Spring会这样调用午餐 饭 美团.下单(黄焖鸡); 小张 张三 new 小张(饭); // 依赖被注入进去了6. 为什么这很好-解耦小张不需要依赖具体的“黄焖鸡”明天他想吃“螺蛳粉”只要换个注入对象就行小张代码不用改。-好测试单元测试时你不需要真的叫外卖直接注入一个“假饭”Mock对象就行。-易维护如果做菜的流程变了比如从燃气灶变成电磁炉小张完全不知情不用改代码。---### 最后用大白话再总结一遍-依赖注入你需要的零件依赖不是你亲手造的而是别人从外面递给你。-控制反转你不再掌握“谁来递”、“什么时候递”的大权大权交给了外部的“总管”容器。所以当你听到“Spring框架通过依赖注入实现了控制反转”你就可以脑补Spring就像那个万能的外卖平台你只要声明你想要什么它就会在合适的时候把东西精确地送到你手上而你完全不用操心过程。