依赖注入听起来高大上，其实说白了就是"别自己动手，等别人送过来"。比如A类需要B类的实例，传统做法是在A内部直接new一个B。而依赖注入则是通过外部传入B的实例，可以是构造函数传参，也可以是方法传参或者属性赋值。这样做最大的好处就是解耦，让类之间的关系更清晰。
先来看个反例。假设我们有个订单处理类：
这段代码的问题在于OrderProcessor和FileLogger紧密耦合。如果想换成数据库日志，就得修改OrderProcessor的代码。这违反了开闭原则，对扩展开放，对修改关闭。
用构造函数注入改造一下：
现在OrderProcessor不关心具体的日志实现，只要传入的对象实现了LoggerInterface接口就行。测试的时候还可以传入模拟对象，方便单元测试。
在实际项目中，我们不可能手动管理所有依赖关系，这时候就需要容器来帮忙。容器就是个自动装配工厂，负责创建对象并解析依赖关系。下面实现个简单的容器：
这个容器支持自动解析构造函数参数，遇到有类型提示的类参数时会递归解析。使用起来也很简单：
在实战中，我们通常会用更成熟的DI容器，比如PHP-DI或Laravel的容器。以Laravel为例，它提供了多种绑定方式：
依赖注入带来的好处是实实在在的。首先是代码可测试性大大提升：
其次是代码更符合面向对象设计原则，各个类职责单一，依赖关系明确。当需要扩展功能时，比如要给日志添加邮件通知，只需要实现新的日志类并修改绑定配置，业务代码完全不用动。
不过也要注意，依赖注入不是银弹。在小型项目中使用可能会显得过度设计，要根据实际情况权衡。另外循环依赖问题也需要避免，如果A依赖B，B又依赖A，容器会抛出异常。
个人建议是从构造函数注入开始，逐步理解控制反转的思想。等项目复杂度上来后，再引入容器管理依赖。记住，工具是为人服务的，不要为了用设计模式而用设计模式。