对我来说，IoC/DI正在向调用对象推出依赖项。超级简单。

非技术性的答案是，在你打开引擎之前，你可以更换汽车的引擎。如果一切正常（界面），你就很好了。

维基百科文章。对我来说，控制反转就是将您按顺序编写的代码转换为委托结构。您的程序不是显式地控制一切，而是设置一个类或库，其中包含发生某些事情时要调用的某些函数。它解决了代码重复。例如，在过去，您可以手动编写自己的事件循环，在系统库中轮询新事件。现在，大多数现代API只需告诉系统库您感兴趣的事件，它会让您知道它们何时发生。控制反转是减少代码重复的一种实用方法，如果您发现自己复制了整个方法，只更改了一小段代码，可以考虑使用控制反转来解决它。在许多语言中，通过委托、接口甚至原始函数指针的概念，控制反转变得容易。它并不适合在所有情况下使用，因为这样编写时，程序的流程可能更难遵循。在编写可重用的库时，这是一种设计方法的有用方法，但除非它真的解决了代码重复问题，否则应该在自己程序的核心中谨慎使用。

控制反转，（或IoC），是关于获得自由（你结婚了，失去了自由，你被控制了。你离婚了，你刚刚实现了控制反转。这就是我们所说的“脱钩”。好的计算机系统阻碍了一些非常亲密的关系。)更灵活（你办公室的厨房只供应干净的自来水，这是你想喝水时的唯一选择。你的老板通过安装一台新的咖啡机实现了控制反转。现在你可以灵活选择自来水或咖啡。)和更少的依赖性（你的伴侣有工作，你没有工作，你在经济上依赖你的伴侣，所以你受到控制。你找到了工作，你实现了控制反转。良好的计算机系统鼓励依赖。）

当你使用台式电脑时，你已经从（或者说，被控制）了。你必须坐在屏幕前看着屏幕。用键盘打字，用鼠标导航。一个写得不好的软件会让你更加痛苦。如果你把桌面换成笔记本电脑，那么你的控制就有点颠倒了。你可以轻松地拿着它四处走动。所以现在你可以用电脑控制你的位置，而不是由电脑控制。

通过实现控制反转，软件/对象消费者可以获得更多的软件/对象控制/选项，而不是被控制或拥有更少的选项。

考虑到上述想法。我们仍然错过了IoC的一个关键部分。在IoC的场景中，软件/对象使用者是一个复杂的框架。这意味着您创建的代码不是自己调用的。现在让我们来解释一下为什么这种方式对web应用程序更有效。

假设您的代码是一组工作人员。他们需要造一辆车。这些工人需要一个地方和工具（软件框架）来制造汽车。一个传统的软件框架就像一个有很多工具的车库。因此，工人们需要自己制定计划，并使用工具来制造汽车。造一辆车不是一件容易的事，工人们很难做好计划并进行适当的合作。一个现代化的软件框架将像一个拥有所有设施和管理人员的现代化汽车工厂。工人不必制定任何计划，管理者（框架的一部分，他们是最聪明的人，制定了最复杂的计划）将帮助协调，以便工人知道何时完成他们的工作（框架调用您的代码）。工人们只需要足够灵活地使用经理给他们的任何工具（通过使用依赖注入）。

尽管工人将项目管理的控制权交给了管理者（框架）。但有一些专业人士帮助是很好的。这就是IoC的真正来源。

具有MVC架构的现代Web应用程序依赖于框架来执行URL路由，并将控制器放置在适当的位置以供框架调用。

依赖注入和控制反转是相关的。依赖注入在微观层面，控制反转在宏观层面。为了完成一顿饭（实现IoC），你必须吃每一口（实现DI）。

我在这里找到了一个非常清楚的例子，它解释了“控制是如何颠倒的”。

经典代码（无依赖注入）

以下是不使用DI的代码大致工作原理：

应用程序需要Foo（例如控制器），因此：应用程序创建Foo应用程序调用FooFoo需要Bar（例如服务），因此：Foo创建BarFoo调用BarBar需要Bim（服务、存储库…），因此：条形图创建Bim酒吧有点事

使用依赖注入

以下是使用DI的代码大致工作原理：

应用程序需要Foo，需要Bar，需要Bim，因此：应用程序创建Bim应用程序创建Bar并赋予它Bim应用程序创建Foo并给它Bar应用程序调用FooFoo调用Bar酒吧有点事

依赖项的控制是从一个被调用到另一个调用的。

它解决了什么问题？

依赖注入使得可以很容易地与注入类的不同实现进行交换。在单元测试时，您可以注入一个虚拟实现，这使测试更加容易。

例如：假设您的应用程序将用户上传的文件存储在Google Drive中，使用DI，您的控制器代码可能如下所示：

class SomeController
{
    private $storage;

    function __construct(StorageServiceInterface $storage)
    {
        $this->storage = $storage;
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

class GoogleDriveService implements StorageServiceInterface
{
    public function authenticate($user) {}
    public function putFile($file) {}
    public function getFile($file) {}
}

当你的需求发生变化时，比如说，你被要求使用Dropbox而不是GoogleDrive。您只需要为StorageServiceInterface编写一个dropbox实现。只要Dropbox实现符合StorageServiceInterface，就不必对控制器进行任何更改。

测试时，您可以使用虚拟实现为StorageServiceInterface创建模拟，其中所有方法都返回null（或根据测试要求的任何预定义值）。

相反，如果您有一个控制器类来构造具有如下新关键字的存储对象：

class SomeController
{
    private $storage;

    function __construct()
    {
        $this->storage = new GoogleDriveService();
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

当您想要使用Dropbox实现进行更改时，必须替换构建新GoogleDriveService对象的所有行，并使用DropboxService。此外，在测试SomeController类时，构造函数总是期望GoogleDriveService类，并触发该类的实际方法。

什么时候合适，什么时候不合适？在我看来，当您认为类有（或可能有）替代实现时，您可以使用DI。

我将写下我对这两个术语的简单理解：

For quick understanding just read examples*

依赖注入（DI）：依赖注入通常意味着将方法依赖的对象作为参数传递给方法，而不是让方法创建依赖对象。这在实践中意味着，该方法不直接依赖于特定的实现；任何满足要求的实现都可以作为参数传递。使用此对象可以告诉它们的依赖关系。春天使它成为可能。这导致了松散耦合的应用程序开发。

Quick Example:EMPLOYEE OBJECT WHEN CREATED,
              IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
   (if address is defines as dependency by Employee object)

控制反转（IoC）容器：这是框架的共同特征，IOC通过其BeanFactory管理java对象——从实例化到销毁-由IoC容器实例化的Java组件称为bean，IoC容器管理bean的范围、生命周期事件以及为其配置和编码的任何AOP特性。

快速示例：控制反转是指获得自由、更大的灵活性和更少的依赖性。当你使用台式电脑时，你是从属的（或者说，受控的）。你必须坐在屏幕前看着屏幕。用键盘打字，用鼠标导航。一个糟糕的书面软件会让你更加痛苦。如果你用笔记本电脑取代了你的桌面，那么你的控制就有点颠倒了。你可以轻松地拿着它四处走动。所以现在你可以用电脑控制你的位置，而不是电脑控制它。

通过实现控制反转，软件/对象消费者可以获得更多的软件/对象控制/选项，而不是被控制或拥有更少的选项。

作为设计指南的控制反转具有以下目的：

某个任务的执行与实现是分离的。每个模块都可以专注于它的设计目的。模块不假设其他系统做什么，而是依赖它们的合同。替换模块对其他模块没有任何副作用，我将在这里保持抽象，您可以访问以下链接以详细了解主题。一个很好的例子

详细说明

真的不明白为什么会有很多错误的答案，甚至被接受的答案也不太准确，这让人很难理解。真相总是简单明了的。

正如@Schneider在@Mark Harrison的回答中所评论的，请阅读Martin Fowler关于IoC的帖子。

https://martinfowler.com/bliki/InversionOfControl.html

我最喜欢的是：

这种现象就是控制反转（也称为好莱坞原则——“不要打电话给我们，我们会打电话给你”）。

为什么？

IoC的Wiki，我可以引用一段话。

控制反转用于增加程序的模块性并使其可扩展。。。随后在2004年由Robert C.Martin和Martin Fowler进一步推广。

Robert C.Martin：《清洁代码：敏捷软件工艺手册》的作者。

马丁·福勒：《重构：改进现有代码的设计》一书的作者。