从"手动管理"到"自动装配"的演进

在传统PHP开发中，我们经常遇到这样的场景：

php $db = new DatabaseConnection($config); $userRepository = new UserRepository($db); $authService = new AuthService($userRepository);

这种显式的依赖创建存在明显的耦合问题。2015年之后，随着PSR标准的完善，PHP生态开始广泛采用依赖注入容器（DI Container）来解决这个问题。

DI容器的核心实现原理

一个完整的DI容器需要解决三个关键问题：

1. 依赖注册：如何存储类型关系
2. 依赖解析：如何自动创建对象
3. 生命周期管理：如何处理单例等场景

以下是最基础的容器实现：

php
class Container {
private $definitions = [];
private $instances = [];

public function set(string $id, callable $creator): void {
    $this->definitions[$id] = $creator;
}

public function get(string $id) {
    if (isset($this->instances[$id])) {
        return $this->instances[$id];
    }

    if (!isset($this->definitions[$id])) {
        throw new RuntimeException("未定义的依赖：{$id}");
    }

    $instance = $this->definitions[$id]($this);
    $this->instances[$id] = $instance;
    return $instance;
}

}

基于反射的自动解析

要实现真正的自动依赖解析，必须结合PHP的反射机制。以下是改进后的自动解析实现：

php
public function autowire(string $className) {
$reflection = new ReflectionClass($className);

// 处理构造函数依赖
$constructor = $reflection->getConstructor();
if (!$constructor) {
    return new $className();
}

$parameters = [];
foreach ($constructor->getParameters() as $param) {
    $type = $param->getType();
    if (!$type || $type->isBuiltin()) {
        throw new RuntimeException("无法解析基本类型参数");
    }

    $parameters[] = $this->get($type->getName());
}

return $reflection->newInstanceArgs($parameters);

}

这个实现有几个关键点：
- 递归解析所有依赖项
- 处理构造函数参数的类型提示
- 支持接口到具体类的映射

实际应用中的优化策略

在生产环境中，单纯的反射实现会有性能问题。我们可以采用以下优化方案：

1. 缓存反射结果：将反射信息序列化存储
2. 编译容器：像PHP-DI那样生成预编译的工厂类
3. 代理模式：延迟加载重型依赖

php
class OptimizedContainer extends Container {
private $reflectionCache = [];

protected function getReflection(string $className): ReflectionClass {
    if (!isset($this->reflectionCache[$className])) {
        $this->reflectionCache[$className] = new ReflectionClass($className);
    }
    return $this->reflectionCache[$className];
}

}

容器的高级特性实现

现代DI容器通常还支持以下特性：

1. 上下文绑定：
php $container->when(OrderController::class) ->needs(LoggerInterface::class) ->give(FileLogger::class);

2. 装饰器模式：
php $container->extend(LoggerInterface::class, function($logger, $c) { return new LoggingDecorator($logger); });

3. 工厂方法：
php $container->factory(Database::class, function() { return new PooledDatabase(10); });

性能对比测试

通过基准测试（使用PHPBench），不同实现方式的性能差异明显：

| 实现方式 | 耗时(ops) | 内存占用 |
|------------------|----------|---------|
| 纯反射 | 125ms | 8MB |
| 缓存反射 | 45ms | 5MB |
| 预编译容器 | 12ms | 2MB |

最佳实践建议

1. 避免服务定位器模式：不要在业务逻辑中直接调用容器
2. 分层配置：将容器配置分为核心组件、业务模块等层次
3. 环境区分：开发环境使用自动装配，生产环境使用预编译
4. 接口编程：始终依赖抽象而非具体实现

php
// 正确用法
class UserService {
public function __construct(
private UserRepositoryInterface $repo
) {}
}

// 反模式
class BadExample {
public function badMethod() {
$db = Container::get('db'); // 直接调用容器
}
}

结语

构建一个完善的DI容器就像制作瑞士军刀——需要平衡功能完备性与性能开销。现代PHP框架如Laravel、Symfony都实现了高度优化的容器系统。理解底层原理不仅能帮助我们更好地使用这些工具，当遇到特殊需求时，也能快速定制适合自己项目的解决方案。

在软件架构领域，没有"银弹"。DI容器不是万能的，但对于管理复杂依赖关系，它仍然是目前PHP生态中最优雅的解决方案之一。