化简为繁把人绕晕版：
首先得先说清几个名词 IoC, DI, SL, DIP。
IoC（控制反转）目前比较流行的两种方式 DI（依赖注入模式） 和 SL（服务器定位模式），DI 是遵循 DIP（依赖反转原则）的，SL 是 anti-pattern（反模式）的，不遵循 DIP。
https://www.cnblogs.com/xiandnc/p/9407856.html
因为注入的形式五花八门，为了代码复用性和扩展性出现了 IoC container 这么个东西，它是遵循各自 DI/SL 模式实现的容器，DI 容器会大量的运用反射机制来实现。
提到的 Laravel 中 Service Container 核心是 illuminate/container 是 DI/SL 的混合体。
其他就不多说了，关于这个概念，可以多读几遍下面这篇文章：
Inversion of Control Containers and the Dependency Injection pattern [译文]
一看就懂版：
紧耦合有依赖的写法:
class Employee
{
Address address;
Employee()
{
address = new Address();
}
}
松耦合没依赖的写法:
class Employee
{
Address address;
Employee(Address address)
{
this.address=address;
}
}
依赖注入最大的两个好处是:
- 代码松耦合, 易维护
- 易测试
a依赖b，b为被依赖项。这时被依赖项b就是动态传进来的而不是在依赖项a中创建的。也就是说这里a和b虽然作为整体存在（即当外界调用a时需要b的参与），但是b的值却是从外界传进来的。这里可不可以理解为一个字“回”当我从外界传进来的是一个“木”字，这时“回”就变成了“困”，传进“人”就变成了“囚”，不知道可不可以这么理解。依赖注入这四个字，依赖：当需调用a对象时，需要b的参与，这时就是a依赖b。注入：是什么意思呢。是不是就是说当调用a对象时就把b对象最为参数传进去呢？
-
本来在函数中写死了，现在不介，代码挪出去，传个参数进来
-
这就是面向过程中，传参数。什么依赖注入，控制反转，唉 ！
-
、
基本思想：
依赖倒置（Dependence Inversion Principle）
解耦和最重要的原则就是依赖倒置原则：
高层模块不应该依赖底层模块，他们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
《资本论》中都曾阐释依赖倒转原则——在商品经济的萌芽时期，出现了物物交换。假设你要买一个IPhone，卖IPhone的老板让你拿一头猪跟他换，可是你并没有养猪，你只会编程。所以你找到一位养猪户，说给他做一个养猪的APP来换他一头猪，他说换猪可以，但是得用一条金项链来换——所以这里就出现了一连串的对象依赖，从而造成了严重的耦合灾难。解决这个问题的最好的办法就是，买卖双发都依赖于抽象——也就是货币——来进行交换，这样一来耦合度就大为降低了。
依赖倒置原则
指的是高级模块不应该依赖低级模块，而是依赖抽象。抽象不能依赖细节，细节要依赖抽象。比如类A内有类B对象，称为类A依赖类B，但是不应该这样做，而是选择类A去依赖抽象。例如垃圾收集器不管垃圾是什么类型，要是垃圾就行。
