Request不能直接注入普通服务，因其为请求级对象而服务默认单例，启动时无请求上下文；Context::get(Request::class)仅在HTTP协程中安全，需判空；推荐按需通过Container::make()获取并配合Context::has()校验。
Hyperf里Request对象为什么不能直接注入到普通服务中
因为Hyperf的协程生命周期和依赖注入容器的初始化时机不匹配：Request 是每次 HTTP 请求进入时才创建的，而普通服务（如 UserService）默认是单例（Singleton），在服务启动时就实例化了——此时根本还没有任何请求上下文，Request 还不存在。
直接在构造函数里写 public function __construct(Request $request) 会触发容器报错：Cannot instantiate interface Hyperf\HttpServer\Contract\RequestInterface，或者更常见的是容器找不到可解析的 Request 实例。
用 ApplicationContext::getContainer()->get(Request::class) 安全吗
不安全，且大概率出错。虽然在协程内看似能拿到，但这个调用依赖当前协程是否已绑定 HTTP 上下文。比如在定时任务、异步队列、WebSocket 连接建立阶段，或手动启动的协程里，Request 根本未被绑定到协程上下文中，get(Request::class) 会返回空或抛异常。
正确做法是只在明确处于 HTTP 请求生命周期内（如控制器、中间件、注解处理器）使用该方式，并加判空：
use Hyperf\Context\Context;
use Hyperf\HttpMessage\Server\Request;
$request = Context::get(Request::class);
if (! $request instanceof Request) {
throw new RuntimeException('No request context available');
}
推荐方案：用工厂类 + @Value 或 make() 延迟获取
把对 Request 的依赖从构造期移到方法执行期，让服务本身保持无状态、可复用。两种实操路径：
- 用
@Value("request")注入（仅限支持@Value的类，如控制器、中间件；普通服务需开启value-annotation扩展并确保扫描到） - 在需要时通过容器
make()获取，配合Context::has()判定可用性
示例（服务内按需获取）：
use Hyperf\Context\Context;
use Hyperf\HttpMessage\Server\Request;
use Hyperf\Di\Annotation\Inject;
class AuthService
{
#[Inject]
protected ContainerInterface $container;
public function getCurrentUserId(): ?int
{
if (! Context::has(Request::class)) {
return null;
}
$request = $this->container->make(Request::class);
return (int)($request->input('user_id') ?? $request->header('x-user-id')[0] ?? 0);
}
}
复杂点在于跨协程传递与测试模拟
如果服务被用于非 HTTP 场景（如 go 启动的后台协程），你得自己把 Request 绑定进去，否则 Context::get() 拿不到：
go(function () use ($request) {
Context::set(Request::class, $request);
// 此处调用 AuthService 就能取到 request
});
单元测试时也容易漏掉这一步——mock 服务行为没问题，但一旦内部调用了 Context::get(Request::class)，没提前 set 就会返回 null，导致逻辑分支跳过。这点比 Laravel 的 request() 辅助函数更显式、也更易出错。
