构造函数注入比@Inject属性注入更轻量：前者不强制生成代理类，仅依赖PHP原生类型提示查容器映射；后者必须生成代理类并触发两次反射与注解解析，增加函数调用、字节码解析及运行时赋值开销。
构造函数注入的代理生成更轻量
Hyperf 在启动时会对所有被扫描到的类生成代理类（Proxy），但两种注入方式触发的代理逻辑不同。构造函数注入不强制生成额外代理，只要类本身没被 AOP 切面标记，容器就直接 new 实例并传参；而 @Inject 属性注入必须依赖代理类在 __construct 之后、方法调用前执行属性赋值，这个代理会包裹原类并重写初始化流程。
这意味着：同一 Service 类若只用构造函数注入，runtime/container/proxies/ 下可能压根不生成对应 Proxy 文件；但只要加了 @Inject，哪怕只在一个属性上，Hyperf 就会为它生成完整代理类 —— 包含反射读取属性、从容器取实例、赋值等固定开销。
- 代理文件体积更大，加载时需解析更多字节码
- 每次实例化都要走代理的 __construct + 初始化钩子，比直连 new 多 1–2 次函数调用
- 如果该类还被
@Aspect或@Middleware标记，代理会叠加，性能衰减更明显
@Inject 注入会触发额外的反射和配置解析
@Inject 不是“标记即生效”，它依赖运行时反射 + 注解解析器两次介入：第一次在 DI 容器构建 Definition 时扫描属性类型，第二次在对象实例化后调用 PropertyInjector 执行赋值。而构造函数注入的类型提示由 PHP 自身在解析参数签名时提供，Hyperf 只需查容器映射表，跳过了注解解析环节。
尤其当属性用了别名注入（如 @Inject("custom_service")）或接口注入（需查 dependencies.php 映射），还会多一次数组键查找或配置遍历。这些操作在服务高频创建场景（如协程内短生命周期对象）下会被放大。
- 反射
ReflectionClass::getProperties()比读取函数参数签名慢约 3–5 倍（实测 10w 次调用） - 注解解析器需逐行解析 DocBlock，即使缓存了 AST，仍比原生类型提示多一层抽象
- 属性注入无法利用 PHP 8.2+ 的
readonly优化，因为赋值发生在构造之后
构造函数注入更容易被 JIT 和 OPcache 优化
PHP 8.0+ 的 JIT 对可预测的函数调用链更友好。构造函数注入的调用路径是静态的：new X($container->get(Y::class)) → 容器查表 → 返回实例。而 @Inject 注入的路径是动态的：new X() → 触发代理 → 反射获取属性 → 解析注解 → 查容器 → 赋值 → 返回，中间混杂着魔术方法和运行时判断。
OPcache 也更倾向缓存构造函数参数明确的类定义。Hyperf 的编译时注解扫描虽能预生成部分元数据，但 @Inject 的最终赋值时机仍在运行时，导致部分优化失效。
- 构造函数注入的类在 OPcache 中命中率更高，冷启动后首次请求更快
- JIT 更可能将
$container->get()内联为直接内存寻址（尤其单例绑定时） - 使用
?UserService等可空类型时，构造函数注入仍保持类型稳定性；@Inject在属性上声明可空则需额外判空逻辑
真实项目里性能差异通常不明显，但边界情况很关键
单次请求中，两种方式的耗时差在 0.01–0.05ms 量级，对 HTTP 接口几乎无感。但以下场景会暴露差距：
- 协程内频繁创建对象（如消息处理循环中每秒千次 new Service）
- CLI 命令批量处理大量记录，每个记录都 new 一个带
@Inject的 Handler - 容器中存在大量未启用 AOP 但误加了
@Inject的类，导致代理泛滥
真正容易被忽略的是：构造函数注入的类一旦被 @Inject 属性污染，整个类就失去“无代理直连”资格——哪怕只有一个属性用了注解，代理就会生成，其他所有构造函数参数的优化也一并失效。
