必须用 requeststack 而非直接注入 request，因为 request 是 request-scoped，构造时无上下文会报错；requeststack 是 container-scoped，可安全延迟获取当前请求，且需在业务方法中调用 getcurrentrequest() 并判空。
不能直接在构造函数里调用 getCurrentRequest()，否则 CLI 或子请求场景会返回 null；必须在业务方法中按需获取并判空。
为什么必须用 RequestStack 而不是直接注入 Request
Symfony 4+ 中 Request 是 request-scoped 对象，而普通服务默认是 container-scoped（单例）。如果强行把 Request 注入服务构造函数，容器会在启动时尝试解析它——此时根本没有 HTTP 请求上下文，会报错或返回过期实例。而 RequestStack 是一个“请求栈管理器”，它本身是容器作用域的，但能安全地在运行时返回当前有效的 Request 实例。
怎么在服务类里正确使用 RequestStack
构造函数接收 RequestStack，保存为属性；在具体方法里调用 getCurrentRequest()，并做非空判断：
- 不要在
__construct()里调用$requestStack->getCurrentRequest() - 每次需要时才调用，比如在
handle()、log()等业务方法内 - 务必检查返回值：
if (!$request = $this->requestStack->getCurrentRequest()) { ... } - CLI 命令中该方法会返回
null，这是正常行为，不是 bug
示例：
use Symfony\Component\HttpFoundation\RequestStack;
class MyService
{
private RequestStack $requestStack;
public function __construct(RequestStack $requestStack)
{
$this->requestStack = $requestStack;
}
public function getCurrentUri(): string
{
$request = $this->requestStack->getCurrentRequest();
if (!$request) {
throw new \LogicException('No active HTTP request');
}
return $request->getRequestUri();
}
}
YAML 配置里要不要加 scope: "request"
不需要。只要服务本身不保存请求相关状态，就保持默认作用域（container）即可。加 scope: "request" 反而会让服务在每次请求中重建，带来不必要的开销，还可能破坏单例语义（比如被缓存、日志等共享服务引用时出错）。
唯一要加 scope: "request" 的情况是：你真需要整个服务生命周期都绑定到某次请求，并且它内部大量依赖 $request 实例（比如某些中间件包装器），但这种需求极少。
常见错误现象和排查点
以下写法都会出问题：
- 构造函数里直接写
$this->request = $requestStack->getCurrentRequest();→ 启动时报LogicException: The session has not been set类似错误 - 配置里给服务加了
scope: "request"，但又把它注入到命令行服务里 → 容器抛出A request-scoped service cannot be used here - 没判空就直接调用
$request->headers→ PHP Fatal error: Call to a member function headers() on null - 在事件监听器里用了
RequestStack，但监听的是kernel.terminate→ 此时请求已结束，getCurrentRequest()返回null
最常被忽略的一点：RequestStack 不等于 Request。它是个“取请求的工具”，不是请求本身；它的价值恰恰在于“延迟”和“安全”，别把它当 Request 的快捷方式来用。
