不能靠@Inject直接根据请求参数动态注入，必须用工厂类在请求处理时调用make()方法，从容器获取Request并依据type参数返回对应NotificationChannelInterface实现。
Hyperf 中如何让容器根据请求参数选择注入类
Hyperf 的依赖注入默认是启动时绑定、运行时解析，不支持“每次请求动态换实现”。想根据 request 参数（比如 type=wechat 或 type=sms）决定注入哪个通知服务，不能靠 @Inject 直接写死类名，得绕过静态绑定，用工厂+运行时 Request 参与决策。
用工厂类封装动态解析逻辑
工厂不是为了“造对象”，而是把“选哪个类”这个判断逻辑集中起来。它必须能访问当前请求上下文，所以得从容器里获取 Request 对象，而不是自己 new 或从构造器传入（否则拿不到当前请求的参数）。
- 工厂类需声明为
singleton，避免每次调用都新建实例 - 不要在构造函数里尝试获取
Request，因为容器初始化早于请求上下文就绪；必须在方法内通过$this->container->get(Request::class)拿 - 返回类型建议用接口（如
NotificationChannelInterface），便于后续扩展
class ChannelFactory
{
public function __construct(protected ContainerInterface $container) {}
public function make(): NotificationChannelInterface
{
$request = $this->container->get(Request::class);
$type = $request->input('type', 'default');
return match ($type) {
'wechat' => $this->container->get(WechatChannel::class),
'sms' => $this->container->get(SmsChannel::class),
default => $this->container->get(DefaultChannel::class),
};
}
}
在 Controller 或 Service 中正确使用工厂
别在属性上用 @Inject 注入工厂后直接调用 make() —— 这看似可行，但容易误以为“注入一次，复用多次”，而实际每次请求的 type 不同，必须确保 make() 在请求处理流程中被调用（即在 action 内或 service 方法内）。
- Controller 里直接调用工厂：安全、清晰，适合简单场景
- Service 层调用时，注意该 Service 本身不能是单例且缓存了工厂返回结果（比如把
$channel存为属性） - 如果用了 AOP 或中间件预处理，确保工厂调用发生在 Request 已绑定之后（Hyperf 默认满足）
class NotifyController
{
public function send(ChannelFactory $factory): string
{
$channel = $factory->make(); // ✅ 每次请求都重新选
$channel->send('hello');
return 'ok';
}
}
为什么不用 @Value 或 @Inject + 条件绑定
有人试过在 @Inject 上加条件注解、或用 @Value("${param.type}")，这些都行不通——@Value 解析的是配置文件或环境变量，不是运行时请求参数；Hyperf 的注解解析器在服务注册阶段执行，此时 Request 根本不存在。
- 容器绑定（
Container::set）无法按请求参数做分支，只支持固定 key → 固定实例 - 试图在
ConfigProvider里读取Request会抛出ContainerException：找不到Request服务 - 唯一可靠路径就是：请求来了 → 有
Request→ 工厂按需查、按需 get
真正容易被忽略的是生命周期错位：工厂本身可以单例，但它内部的 make() 必须每次调用都重新走一遍请求参数判断。一旦把这个逻辑提前固化（比如塞进构造器、或存在属性里），就退化成静态绑定，参数切换完全失效。
