hyperf 3.0 中依赖注入不支持 = null 作为非可空类型的默认值，必须显式声明为 ?userservice 或 userservice|null，容器在服务未注册时才注入 null，且需在使用前判空。
Hyperf 3.0 中依赖注入不支持 null 作为默认值
Hyperf 3.0 基于 PHP 8.0+，但其 DI 容器在解析构造函数或方法参数时，**不会把 = null 当作“可选依赖”的信号**。如果你写 public function __construct(private UserService $service = null)，PHP 会直接报错：Fatal error: Default value for parameters with a class type hint can only be NULL if the type is nullable。这不是 Hyperf 的 bug，而是 PHP 强制要求：非可空类型不能配 = null 默认值。
- 必须显式声明类型为可空，例如
?UserService或UserService|null -
= null只能出现在可空类型之后，且是唯一合法的默认值（不能写= 'default'） - Hyperf 的容器在实例化时，对
?UserService $service = null会尝试从容器中解析UserService；如果未绑定，才真正注入null
?Service 和 Service|null 在 Hyperf 里效果一致但推荐后者
Hyperf 3.0 完全兼容 PHP 8.0 联合类型，?UserService 是语法糖，等价于 UserService|null。但用 UserService|null 更清晰——尤其当你要配合 mixed、string|int 等联合类型时，统一用 | 风格避免混淆。
- 接口定义中优先用
UserService|null：IDE 和 PHPStan 能更好推导分支逻辑 - 若服务可能未注册（比如插件模块按需启用），用
UserService|null显式表达“该依赖非必需” - 不要混用：写成
?UserService $svc = null合法，但UserService|null $svc = null才更直觉、更易被静态分析工具覆盖
实际场景：如何安全地注入一个可能不存在的服务
典型例子是日志驱动、通知通道、第三方 SDK 客户端等可插拔组件。你不想让主流程因某个可选服务缺失而崩溃。
- 声明为
private ?NotificationClient $client = null（属性）或public function __construct(private NotificationClient|null $client = null)（构造器） - 使用前必须判空：
if ($this->client !== null) { $this->client->send(...); }—— 不能只靠isset()或empty()，因为对象可能为 falsey - 避免在
__construct中对可空依赖做业务逻辑（如调用$this->client->ping()），否则容器构建失败时整个类不可用 - 如需 fallback 行为，建议封装一层适配器，而非在业务方法里堆砌
if-else
容易被忽略的陷阱：Hyperf 的 AOP 和注解代理会绕过可空检查
当你用 @Inject 注解或 AOP 切面增强类时，Hyperf 会生成代理类。如果原始方法签名含 ?UserService $svc = null，代理类可能因反射或参数绑定逻辑，把 null 当作未传参而跳过注入，导致运行时 $svc 是 undefined 或触发严格模式错误。
- 始终用
UserService|null替代?UserService，减少代理层歧义 - 在
@Aspect类中，避免对可空参数做无条件调用；先is_null()再操作 - 单元测试时，手动 new 实例并传
null，比依赖容器注入更能暴露这类问题
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
