Symfony 请求处理以 Request 对象为核心，需在控制器动作中通过类型提示注入；区分 query/request/files/headers/attributes 访问器获取数据；表单处理须匹配请求类型；子请求独立，需显式传参获取主请求信息。
Symfony 中的请求处理围绕 Request 对象展开，它封装了原始 HTTP 请求的所有信息（如查询参数、表单数据、文件上传、头信息、会话等），并提供统一、面向对象的操作接口。关键不在于“怎么拿到 Request”，而在于“在哪儿用、怎么用、用对没”。
控制器中正确注入和使用 Request 对象
Request 对象应通过控制器动作方法的参数类型提示自动注入，而不是手动 new 或从服务容器获取：
- 确保方法签名明确声明
Request $request，例如：public function editAction(Request $request, int $id) - 不要在非动作方法（如辅助函数
isLoggedIn()）中直接声明Request参数——它不会被自动传递，会报“参数未给定”错误 - 若需在类内其他方法中访问请求，应通过
$this->getRequest()（旧版）或更推荐的方式：在动作方法中获取所需数据（如 session、query、request attributes），再传入辅助方法
区分不同请求类型的数据提取方式
不是所有数据都走同一个入口。Request 提供了语义清晰的访问器，避免混用 $_GET/$_POST：
-
查询参数（URL ?key=value）：用
$request->query->get('key') -
表单提交数据（POST/PUT）：用
$request->request->get('field') -
上传文件：用
$request->files->get('upload_field')，返回UploadedFile实例，不是字符串 -
请求头：用
$request->headers->get('User-Agent') -
路由参数（如 /post/{id}）：用
$request->attributes->get('id')
表单提交必须匹配请求逻辑
表单处理不是只靠 handleRequest() 就万事大吉，需按实际请求场景选择绑定方式：
- 标准 HTML 表单（
method="POST"）：直接用$form->handleRequest($request) - JSON API 请求（
Content-Type: application/json）：需先json_decode($request->getContent(), true)，再调用$form->submit($data) - PUT/PATCH 请求：确保启用了
HttpMethodOverrideListener，且路由允许对应 method；handleRequest()可正常工作 - 测试或 CLI 场景下绕过 CSRF：构建表单时加选项
['csrf_protection' => false]
子请求与主请求的识别要点
在嵌入式控制器（{% render %}）或 ESI 片段中，每个渲染都是独立的子请求，app.request 指向当前子请求，而非原始主请求：
- 无法直接从子控制器中“回溯”获取主请求对象
- 如需主请求信息（如主控制器名、原始路由参数），必须显式通过
with传参，例如：{% render 'App:Widget:menu' with {'_controller': app.request.attributes.get('_controller')} %} - 子请求的生命周期独立，其 session、attributes、query 等均隔离
