PHP 8 属性怎么做轻量依赖注入：反射注册与可测试边界

项目里的服务只有六七个时，直接在控制器里写 new Mailer() 很快；等到 OrderService 同时依赖仓储、日志和通知器，构造代码就开始到处重复。PHP 8 的属性和反射可以把“某个类由容器创建”这件事写在类声明附近，用几十行代码完成一个可读、可测试的轻量依赖注入容器。

轻量容器的重点不是自动解决所有依赖，而是只负责构造器注入、明确失败原因，并把单例和测试替身的边界留在应用代码里。

先把依赖关系写成一条能验收的链

先用订单通知做例子。OrderService 不关心邮件客户端怎么连接 SMTP，它只需要一个 Notifier 接口；真正的 MailNotifier 再依赖 Mailer。这条链很短，却足以展示容器需要处理的两种情况：具体类可以反射创建，接口必须由应用显式绑定。

mailer->deliver($recipient, $message);
    }
}

#[Service]
final class OrderService
{
    public function __construct(private Notifier $notifier) {}

    public function confirm(string $email): void
    {
        $this->notifier->send($email, '订单已确认');
    }
}

这里的关键不是属性本身，而是依赖方向：业务类依赖接口，基础设施类依赖具体实现。容器只负责把这条链拼起来，不应该把业务规则藏进反射代码。

用 PHP 8 属性标记可构造服务

属性类只承担一个标记职责。不要在属性里塞连接字符串、环境变量或业务配置，否则容器会逐渐变成另一个配置系统。

如果项目最低版本是 PHP 8.0，这段代码可以直接使用。运行前可用 php -v 核对版本；如果团队仍有 PHP 7.4 节点，属性语法会在加载文件时直接失败，不要用条件判断掩盖版本不一致。

反射解析构造器：只做三件事

容器的核心是 make()：先检查类是否带有 Service 属性，再读取构造器参数。如果参数是内置类型且没有默认值，或者参数类型是接口但没有绑定，都应该立刻抛出带上下文的异常。

bindings[$abstract] = [$concrete, $shared];
    }

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

        [$concrete, $shared] = $this->bindings[$id] ?? [$id, false];
        $object = $this->make($concrete);

        if ($shared) {
            $this->shared[$id] = $object;
        }

        return $object;
    }

    private function make(string $class): object
    {
        $reflection = new ReflectionClass($class);
        if ($reflection->getAttributes(Service::class) === []) {
            throw new RuntimeException("服务未标记: {$class}");
        }

        $constructor = $reflection->getConstructor();
        if ($constructor === null) {
            return $reflection->newInstance();
        }

        $arguments = [];
        foreach ($constructor->getParameters() as $parameter) {
            $type = $parameter->getType();
            if (!$type instanceof ReflectionNamedType || $type->isBuiltin()) {
                if ($parameter->isDefaultValueAvailable()) {
                    $arguments[] = $parameter->getDefaultValue();
                    continue;
                }
                throw new RuntimeException("无法解析 {$class}::{$parameter->getName()}");
            }

            $dependency = $type->getName();
            if (interface_exists($dependency) && !isset($this->bindings[$dependency])) {
                throw new RuntimeException("接口未绑定: {$dependency}");
            }
            $arguments[] = $this->get($dependency);
        }

        return $reflection->newInstanceArgs($arguments);
    }
}

这段实现刻意保持克制：没有方法注入、没有自动扫描文件夹、没有循环依赖修复。每加一个“方便”能力，调试时就多一层隐式行为。先让失败信息可读，再考虑扩展。

接口绑定决定了容器是不是可控

启动时显式写绑定，读代码的人能马上看到实际实现。下面的 shared 只对无状态或连接复用型对象开启；业务服务默认按需创建，避免一个请求内意外共享可变状态。

bind(Notifier::class, MailNotifier::class, shared: true);

$service = $container->get(OrderService::class);
$service->confirm('reader@example.test');

核对点有两个：$container->get(OrderService::class) 能拿到对象；第二次取得 Notifier 时，如果绑定为共享实例，返回值应与第一次相同。若接口绑定写成了自身，容器应在启动检查时尽早失败，而不是等到第一笔订单才暴露。

测试时不要让共享实例越过用例边界

可测试性是这个小容器最值得保留的理由。测试订单确认逻辑时，不需要真的发邮件，只要把 Notifier 替换为记录调用的内存实现。

messages[] = [$recipient, $message];
    }
}

$fake = new MemoryNotifier();
$service = new OrderService($fake);
$service->confirm('test@example.test');

assert($fake->messages === [['test@example.test', '订单已确认']]);

注意这里直接构造业务服务，而不是把测试替身塞进一个静态容器。这样测试的依赖在测试文件里可见，也不会因为上一个用例留下共享对象而出现顺序依赖。

哪些扩展信号说明应该停手

当类开始出现标量配置、联合类型、循环依赖、工厂参数和多套生命周期时，继续给这个容器打补丁通常不划算。尤其是自动扫描文件夹，表面上少了几行绑定，实际上会让启动顺序、缓存和错误位置都变得模糊。

架构模式的价值不在于代码越少越好，而在于它把选择限制在可解释范围内。一个只能处理对象构造的容器，反而比“什么都能自动解决”的黑盒更容易维护。

常见问题

PHP 属性和注解有什么区别？

属性是 PHP 8 原生语法，运行时可以通过反射读取；旧式注解通常只是注释，需要额外解析器。新项目优先使用属性，但仍要核对部署节点的 PHP 版本。

为什么不直接让容器实例化接口？

接口没有唯一实现，容器无法凭空判断应该选择邮件、短信还是测试替身。显式绑定能把架构决定留在启动配置中。

共享实例是不是就是单例模式？

它只是当前容器生命周期内复用对象，不等于进程级全局单例。请求结束后是否销毁、常驻进程是否重置，都要由运行环境决定。

什么时候应该换成熟依赖注入容器？

当项目需要自动装配标量参数、生命周期管理、装饰器、编译缓存或循环依赖诊断时，就不建议继续扩展这个示例容器。

最后的判断清单

• 业务类是否只依赖接口，而不是在方法内部创建基础设施对象？
• 所有接口绑定是否集中且能在启动阶段读懂？
• 测试替身能否直接传入构造器，而不依赖全局容器重置？
• 遇到无法解析的参数时，异常是否包含类名和参数名？
• 新增需求是否已经超过“构造器对象注入”的范围？

如果前四项都能回答“是”，这个轻量实现就完成了它的工作；第五项若变成“是”，优先重新评估工具边界，不要把反射代码继续堆成框架。